Microsoft® Windows Server 2003 Unleashed, R2 Edition

Next Page

Book Cover
Microsoft® Windows Server 2003 Unleashed, R2 Edition
By Rand Morimoto, Michael Noel, Alex Lewis
...............................................
Publisher: Sams
Pub Date: May 10, 2006
Print ISBN-10: 0-672-32898-4
Print ISBN-13: 978-0-672-32898-5
Pages: 1368

Table of Contents | Index
Overview

Microsoft Windows Server 2003 Unleashed, 3rd Edition is the first book on the market to cover Windows Server 2003 R2. This latest edition will keep the text viable with the major "R2" update being released from Microsoft late in 2005. Many of the Windows Server 2003 titles have not been revised since release in 2003 even though Microsoft has released a service pack and now the R2 update.

This book will provide detailed guidance focused on the most commonly used yet most complicated planning, installation, migration, and problem solving topics that challenge IT professionals. This title goes far beyond the basic installation and setup information found in hundreds of other resources and focus on the less understood yet most important details for system configuration, tips, tricks, and techniques to successfully implement and administer a Windows networking system.

Next Page


Table of Contents

Previous Page
Next Page

Book Cover
Microsoft® Windows Server 2003 Unleashed, R2 Edition
By Rand Morimoto, Michael Noel, Alex Lewis
...............................................
Publisher: Sams
Pub Date: May 10, 2006
Print ISBN-10: 0-672-32898-4
Print ISBN-13: 978-0-672-32898-5
Pages: 1368

Table of Contents | Index

Copyright
About the Authors
Acknowledgments
We Want to Hear from You!
Introduction
Part I: Windows Server 2003 Overview
 | Chapter 1. Windows Server 2003 Technology Primer
 |  | Windows Server 2003 Defined
 |  | Choosing to Implement Windows Server 2003
 |  | When Is the Right Time to Migrate?
 |  | Versions of Windows Server 2003
 |  | What's New in Windows Server 2003?
 |  | Windows Server 2003 Benefits for Administration
 |  | Windows Server 2003 for Better User Services
 |  | Benefits for Thin Client Terminal Services
 |  | Benefits for Improved Management
 |  | Extending the Directory Beyond Active Directory
 |  | Going Beyond the Basic Features of Windows 2003 with Feature Packs
 |  | Extending the Capabilities of Windows 2003 with Downloadable Tools
 |  | Getting Started with Windows Server 2003
 |  | Best Practices
 | Chapter 2. Planning, Prototyping, Migrating, and Deploying Windows Server 2003 Best Practices
 |  | Determining the Scope of Your Project
 |  | Identifying the Business Goals and Objectives to Implement Windows Server 2003
 |  | Identifying the Technical Goals and Objectives to Implement Windows Server 2003
 |  | The Discovery Phase: Understanding the Existing Environment
 |  | The Design Phase: Documenting the Vision and the Plan
 |  | The Migration Planning Phase: Documenting the Process for Migration
 |  | The Prototype Phase: Creating and Testing the Plan
 |  | The Pilot Phase: Validating the Plan to a Limited Number of Users
 |  | The Migration/Implementation Phase: Conducting the Migration or Installation
 |  | Summary
 |  | Best Practices
 | Chapter 3. Installing Windows Server 2003
 |  | Preplanning and Preparing a Server Installation
 |  | Setting Up the Windows Server 2003 Operating System
 |  | Upgrading to Windows Server 2003
 |  | Using Alternative Methods of Installation
 |  | Performing an Unattended Windows Server 2003 Installation
 |  | Installing Windows Server 2003 from an Image
 |  | Installing Windows Server 2003 with Group Policy and Systems Management Server
 |  | Updating a Windows 2003 Server with a Service Pack
 |  | Preparing a System and Installing the Windows 2003 R2 Components
 |  | Summary
 |  | Best Practices
Part II: Windows Server 2003 Active Directory
 | Chapter 4. Active Directory Primer
 |  | The Evolution of Directory Services
 |  | Understanding the Development of Active Directory
 |  | Active Directory's Structure
 |  | Active Directory's Components
 |  | Domain Trusts
 |  | Organizational Units
 |  | The Role of Groups in an Active Directory Environment
 |  | Active Directory Replication
 |  | The Role of DNS in Active Directory
 |  | Active Directory Security
 |  | Active Directory Changes in Windows Server 2003
 |  | Summary
 |  | Best Practices
 | Chapter 5. Designing a Windows Server 2003 Active Directory
 |  | Active Directory Domain Design
 |  | Choosing Your Domain Namespace
 |  | New Domain Design Features in Windows Server 2003
 |  | Choosing Your Domain Structure
 |  | Single Domain Model
 |  | Multiple Domain Model
 |  | Multiple Trees in a Single Forest Model
 |  | Federated Forests Design Model
 |  | Peer-Root Domain Model
 |  | Placeholder Domain Model
 |  | Special-Purpose Domain Design Models
 |  | Renaming an Active Directory Domain
 |  | Summary
 |  | Best Practices
 | Chapter 6. Designing Organizational Unit and Group Structure
 |  | Defining Organizational Units in Active Directory
 |  | AD Groups
 |  | OU and Group Design
 |  | Starting an OU Design
 |  | Using OUs to Delegate Administration
 |  | Group Policies and OU Design
 |  | Understanding Group Design
 |  | Sample Design Models
 |  | Summary
 |  | Best Practices
 | Chapter 7. Active Directory Infrastructure
 |  | Understanding Active Directory Replication
 |  | Active Directory Sites
 |  | Planning Replication Topology
 |  | Windows Server 2003 IPv6 Support
 |  | Real-World Replication Designs
 |  | Summary
 |  | Best Practices
 | Chapter 8. Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories
 |  | Understanding and Using Services for Unix 3.5
 |  | Subsystem for Unix-Based Applications as a Component of Services for Unix
 |  | Sharing Files Between Unix NFS and Windows
 |  | Taking Advantage of User Synchronization in SFU
 |  | Administrative Improvements in Services for Unix
 |  | Connecting Windows and NetWare Environments with Services for NetWare
 |  | Microsoft Identity Integration Server 2003
 |  | Harnessing the Power and Potential of MIIS
 |  | Working with Active Directory Federation Services
 |  | Summary
 |  | Best Practices
Part III: Network Services
 | Chapter 9. The Domain Name System
 |  | Inside the Domain Name System
 |  | Framework for DNS
 |  | Getting Started with DNS on Windows Server 2003
 |  | Understanding Resource Records
 |  | DNS Zones
 |  | Zone Transfers
 |  | DNS Queries
 |  | Other DNS Components
 |  | The Evolution of Microsoft DNS
 |  | DNS Changes in Windows Server 2003
 |  | DNS in an Active Directory Environment
 |  | Troubleshooting DNS
 |  | Summary
 |  | Best Practices
 | Chapter 10. DHCP/WINS/Domain Controllers
 |  | Overview of the "Other" Network Services
 |  | Key Components of an Enterprise Network
 |  | Dynamic Host Configuration Protocol (DHCP)
 |  | DHCP Changes in Windows Server 2003
 |  | DHCP Failover
 |  | Advanced DHCP Concepts
 |  | DHCP Security
 |  | The Windows Internet Naming Service
 |  | Installing and Configuring WINS
 |  | Planning, Migrating, and Maintaining WINS
 |  | Global Catalog Domain Controller Placement
 |  | Summary
 |  | Best Practices
 | Chapter 11. Internet Information Services v6
 |  | Improvements in IIS 6
 |  | Planning and Designing IIS
 |  | Installing and Upgrading IIS
 |  | Configuring IIS
 |  | Configuring and Optimizing Applications
 |  | Installing and Configuring FTP Services
 |  | Examining Optional IIS Components
 |  | Securing IIS
 |  | Maintaining IIS
 |  | Internet Explorer Enhanced Security Configuration for Servers
 |  | Summary
 |  | Best Practices
Part IV: Security
 | Chapter 12. Server-Level Security
 |  | Defining Windows Server 2003 Security
 |  | Deploying Physical Security
 |  | Hardening Server Security
 |  | Using Security Templates to Secure a Server
 |  | File-Level Security
 |  | Additional Security Mechanisms
 |  | Using Windows Server Update Services
 |  | Summary
 |  | Best Practices
 | Chapter 13. Transport-Level Security
 |  | Introduction to Transport-Level Security in Windows Server 2003
 |  | Virtual Private Networks
 |  | Public Key Infrastructure
 |  | Using IPSec Encryption with Windows Server 2003
 |  | Configuring Simple IPSec Between Servers in a Windows Server 2003 Domain
 |  | Summary
 |  | Best Practices
 | Chapter 14. Windows Server 2003 Passports
 |  | The Benefits of Using .NET Passports
 |  | Installing and Configuring .NET Passports
 |  | Working with .NET Passport Accounts
 |  | Using Passports with Web-Based Applications
 |  | Using .NET Passports and Mobile Devices
 |  | Additional Layers of Security
 |  | .NET Passport Policies
 |  | Other Passport Services
 |  | Passport Licensing
 |  | Summary
 |  | Best Practices
 | Chapter 15. Security Policies and Tools
 |  | Security Policies
 |  | Security Framework
 |  | Windows Server 2003 Security Policy Toolbox
 |  | Summary
 |  | Best Practices
Part V: Migrating to Windows Server 2003
 | Chapter 16. Migrating from Windows NT4 to Windows Server 2003
 |  | Migration Paths to Windows Server 2003
 |  | Preparing Windows NT4 Domains to Migrate to Windows Server 2003
 |  | Performing an Inplace Upgrade
 |  | Migrating Existing NT4 Domains to a New Windows Server 2003 Forest
 |  | Consolidating Windows NT4 Domains
 |  | Using Microsoft Active Directory Migration Tool
 |  | Summary
 |  | Best Practices
 | Chapter 17. Migrating from Windows 2000 to Windows Server 2003
 |  | Windows Server 2003 Migration Overview
 |  | Beginning the Migration Process
 |  | Upgrading a Single Member Server
 |  | Upgrading a Windows 2000 Active Directory Forest
 |  | Upgrading Separate AD Forests to a Single Forest Using Mixed-Mode Domain Redirect
 |  | Consolidating and Migrating Domains Using the Active Directory Migration Tool v2.0
 |  | Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT v2.0
 |  | Summary
 |  | Best Practices
 | Chapter 18. Compatibility Testing for Windows Server 2003
 |  | The Importance of Compatibility Testing
 |  | Preparing for Compatibility Testing
 |  | Researching Products and Applications
 |  | Verifying Compatibility with Vendors
 |  | Lab-Testing Existing Applications
 |  | Documenting the Results of the Compatibility Testing
 |  | Determining Whether a Prototype Phase Is Required
 |  | Summary
 |  | Best Practices
Part VI: Windows Server 2003 Administration and Management
 | Chapter 19. Windows Server 2003 Administration
 |  | Defining the Administrative Model
 |  | Examining Active Directory Site Administration
 |  | Configuring Sites
 |  | Examining Windows Server 2003 Active Directory Groups
 |  | Creating Groups
 |  | Handling User Administration
 |  | Understanding User Profiles
 |  | Managing Users with Local Security and Group Policies
 |  | Managing Printers with Print Management Component
 |  | Summary
 |  | Best Practices
 | Chapter 20. Windows Server 2003 System Registry
 |  | Windows Server 2003 Registry Architecture
 |  | The Windows Server 2003 Registry Editor
 |  | Protecting the Registry
 |  | Maintaining the Registry
 |  | Backing Up the Registry
 |  | Summary
 |  | Best Practices
 | Chapter 21. Windows Server 2003 Group Policies
 |  | Leveraging Group Policies
 |  | General Best Practices for Group Policy Deployment
 |  | Understanding GP Inheritance and Application Order
 |  | Understanding the Effects of Slow Links on Group Policy
 |  | Using Tools to Make Things Go Faster
 |  | Linking Group Policies
 |  | Automating Software Installations
 |  | Enhancing Manageability with Group Policy Management Console
 |  | Using Resultant Set of Policies in GPMC
 |  | Understanding Windows Management Instrumentation
 |  | Maximizing Security with Group Policy
 |  | Getting the Most Out of Folder Redirection
 |  | Other Useful Tools for Managing Group Policies
 |  | Using Administrative Templates
 |  | Modifying Administrative Templates
 |  | Working with Group Policy Objects
 |  | Working Within the Group Policy Snap-in Namespace
 |  | Summary
 |  | Best Practices
 | Chapter 22. Windows Server 2003 Management and Maintenance Practices
 |  | Managing Windows Server 2003
 |  | Auditing the Environment
 |  | Managing Windows Server 2003 Remotely
 |  | Identifying Security Risks
 |  | Tracking and Managing Licenses
 |  | Using Microsoft Operations Manager to Simplify Management
 |  | Employing Windows Server 2003 Maintenance Practices
 |  | Keeping Up with Service Packs and Updates
 |  | Maintaining Windows Server 2003
 |  | Summary of Maintenance Tasks and Recommendations
 |  | Summary
 |  | Best Practices
 | Chapter 23. Automating Tasks Using Windows Server 2003 Scripting
 |  | Scripting Overview
 |  | Introduction to VBScript
 |  | Active Directory Scripting Overview
 |  | Discovering Object Properties
 |  | Scripting User Management
 |  | Creating a User from File Data
 |  | Searching Active Directory
 |  | Windows Server 2003 Scripting
 |  | Leveraging Sample Scripts
 |  | Summary
 |  | Best Practices
 | Chapter 24. Documenting a Windows Server 2003 Environment
 |  | Benefits of Documentation
 |  | Design and Planning Documentation
 |  | Migration Documentation
 |  | Active Directory Infrastructure
 |  | Network Infrastructure
 |  | Administration and Maintenance Documentation
 |  | Disaster Recovery Documentation
 |  | Performance Documentation
 |  | Security Documentation
 |  | Training Documentation
 |  | Summary
 |  | Best Practices
 | Chapter 25. Integrating Microsoft Operations Manager with Windows Server 2003
 |  | What Is Microsoft Operations Manager?
 |  | How MOM Works
 |  | Outlining MOM Architecture
 |  | How to Use MOM
 |  | Exploring Management Packs
 |  | MOM Component Requirements
 |  | Advanced MOM Concepts
 |  | MOM Security
 |  | Identifying Sample Designs of Successful MOM Implementations
 |  | Summary
 |  | Best Practices
Part VII: Remote and Mobile Technologies
 | Chapter 26. Remote and Mobile Access
 |  | Windows Server 2003 Routing and Remote Access Features and Services
 |  | Routing and Remote Access Service Architecture
 |  | Virtual Private Networking in Windows 2003
 |  | Authentication Options to an RRAS System
 |  | VPN Protocols
 |  | Choosing Between PPTP and L2TP/IPSec
 |  | Installing and Configuring Routing and Remote Access
 |  | Configuring Remote Access Clients
 |  | RRAS Tools and Utilities
 |  | Leveraging the Capabilities of the Quarantine Policy Check Tool
 |  | Remote Access Scenarios
 |  | Summary
 |  | Best Practices
 | Chapter 27. Windows Server 2003 Terminal Services
 |  | Why Implement Terminal Services?
 |  | How Terminal Services Works
 |  | Leveraging Terminal Services Features
 |  | Planning for Terminal Services
 |  | Deploying Terminal Services
 |  | Configuring Terminal Services
 |  | Installing a Terminal Services License Server
 |  | Installing and Configuring Fault-Tolerant Terminal Services
 |  | Securing Terminal Services
 |  | Sizing and Optimizing Terminal Services Environments
 |  | Supporting Terminal Services
 |  | Accessing a Terminal Server
 |  | Summary
 |  | Best Practices
Part VIII: Desktop Administration
 | Chapter 28. Windows Server 2003 Administration Tools for Desktops
 |  | Examining Desktop Deployment Options
 |  | Using Remote Installation Services to Deploy System Images
 |  | Creating Windows XP Images
 |  | Managing Windows XP Installation Media and Image Versions
 |  | Updating Existing XP and 2000 Workstations
 |  | Managing Desktop Applications
 |  | Managing Windows XP Desktops Remotely
 |  | Summary
 |  | Best Practices
 | Chapter 29. Group Policy Management for Network Clients
 |  | Leveraging the Power of Group Policy
 |  | Baseline Administration for Group Policy Deployment
 |  | General Recommendations for Managing Clients Through Group Policy
 |  | Using Group Policy for System Updates and Patch Management
 |  | Real-Life Scenarios of Group Policy Management
 |  | Summary
 |  | Best Practices
Part IX: Fault Tolerance Technologies
 | Chapter 30. File System Fault Tolerance
 |  | Examining Windows Server 2003 File System Services
 |  | Using Fault-Tolerant Disk Arrays
 |  | Managing File Share Access and Volume Usage
 |  | Leveraging the Capabilities of File Server Resource Manager
 |  | Monitoring Disks and Volumes
 |  | Working with Operating System Files: Fault Tolerance
 |  | Using the Distributed File System Replication
 |  | Planning a DFS Deployment
 |  | Installing DFS
 |  | Optimizing DFS
 |  | Managing and Troubleshooting DFS
 |  | Backing Up DFS
 |  | Handling Remote Storage
 |  | Using the Volume Shadow Copy Service
 |  | Summary
 |  | Best Practices
 | Chapter 31. System-Level Fault Tolerance (Clustering/Network Load Balancing)
 |  | Building Fault-Tolerant Systems
 |  | Examining Windows Server 2003 Clustering Technologies
 |  | Choosing the Right Clustering Technology
 |  | Implementing Cluster Service
 |  | Installing Cluster Service
 |  | Managing Clusters
 |  | Backing Up and Restoring Clusters
 |  | Upgrading Cluster Nodes
 |  | Installing Network Load Balancing Clusters
 |  | Managing NLB Clusters
 |  | Summary
 |  | Best Practices
 | Chapter 32. Backing Up a Windows Server 2003 Environment
 |  | Disaster Recovery Planning
 |  | Discovery: Learning the Environment
 |  | Documenting the Enterprise
 |  | Developing a Backup Strategy
 |  | Backing Up the Windows Server 2003 Operating System and Services
 |  | Examining the Windows Server 2003 Backup Programs
 |  | Virtual Disk Service
 |  | Using the Windows Server 2003 Backup Utility (ntbackup.exe)
 |  | Using Remote Storage
 |  | Using the Volume Shadow Copy Service
 |  | Windows Server 2003 Service Backup Options
 |  | Media Management for Windows Server 2003 Backup and the Remote Storage Service
 |  | Windows Server 2003 Startup Troubleshooting Utilities
 |  | Summary
 |  | Best Practices
 | Chapter 33. Recovering from a Disaster
 |  | Validating Backup Data and Procedures
 |  | Isolating Failures
 |  | Site Failure Recovery
 |  | Recovering from a Disk Failure
 |  | Resolving Boot Failure Problems
 |  | Recovering from a Complete Server Failure
 |  | Resolving Windows Server 2003 Networking Services Errors
 |  | Re-creating Windows Server 2003 File Services and Data
 |  | Restoring Internet Information Services
 |  | Re-establishing the Cluster Service
 |  | Resolving Windows Server 2003 Domain Controller Failure
 |  | Restoring Active Directory
 |  | Recovering the Removable Storage Database
 |  | Restoring Remote Storage Database
 |  | Achieving 99.999% Uptime Using Windows Server 2003
 |  | Summary
 |  | Best Practices
Part X: Problem Solving, Debugging, and Optimization
 | Chapter 34. Logging and Debugging
 |  | Using the Task Manager for Logging and Debugging
 |  | Using the Event Viewer
 |  | System Monitoring
 |  | Setting Baseline Values
 |  | Network Monitoring in Windows Server 2003
 |  | Using the Debugging Tools Available in Windows Server 2003
 |  | Summary
 |  | Best Practices
 | Chapter 35. Capacity Analysis and Performance Optimization
 |  | Defining Capacity Analysis
 |  | Establishing Policy and Metric Baselines
 |  | Using Capacity-Analysis Tools
 |  | Monitoring System Performance
 |  | Optimizing Performance by Server Roles
 |  | Using Server Performance Analyzer 2.0
 |  | Using the Windows System Resource Manager
 |  | Managing Patches
 |  | Summary
 |  | Best Practices
Part XI: Integrated Windows Application Services
 | Chapter 36. Windows SharePoint Services
 |  | The History of SharePoint Technologies
 |  | Identifying the Need for Windows SharePoint Services
 |  | Installing Windows SharePoint Services
 |  | Exploring Basic Windows SharePoint Services Features
 |  | Exploring End User Features in WSS
 |  | Customizing and Developing WSS Sites
 |  | Summary
 |  | Best Practices
 | Chapter 37. Windows Media Services
 |  | Understanding Windows Media Services
 |  | Using Windows Media Services for Real-Time Live Broadcasts
 |  | Broadcasting Stored Single Files
 |  | Hosting a Directory of Videos for On-Demand Playback
 |  | Combining Multiple Files for a Combined Single Broadcast
 |  | Understanding Windows Media Encoder
 |  | Broadcasting a Live Event
 |  | Capturing Audio or Video for Future Playback
 |  | Using Other Windows Media Encoder Options
 |  | Using Microsoft Producer for Sophisticated Presentations
 |  | Summary
 |  | Best Practices
 | Appendix
 |  | License Agreement
 |  | Microsoft Software
Index

Previous Page


Copyright

Microsoft Windows Server 2003 Unleashed, R2 Edition

Copyright © 2006 by Sams Publishing

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

Library of Congress Catalog Card Number: 2006901232

Printed in the United States of America

First Printing: May 2006

09 08 07 06 4 3 2 1

Trademarks

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Sams Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The authors and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the CD or programs accompanying it.

Bulk Sales

Sams Publishing offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact

U.S. Corporate and Government Sales
1-800-382-3419
corpsales@pearsontechgroup.com

For sales outside of the U.S., please contact

International Sales
1-317-428-3341
international@pearsontechgroup.com

Associate Publisher
Greg Wiegand
Acquisitions Editor
Neil Rowe
Development Editor
Mark Renfrow
Managing Editor
Charlotte Clapp
Senior Project Editor
Matthew Purcell
Indexer
Cheryl Lenser
Proofreader
Kathy Bidwell
Contributing Author
Tyson Kopczynski
Technical Editor
Convergent Computing
Publishing Coordinator
Cindy Teeters
Book Designer
Gary Adair
Page Layout
Nonie Ratcliff

Dedication

I dedicate this book to my mother Vickie. Thank you for all you and dad did for me! Something I never really appreciated until I began raising children of my own. I brag about you all the time of the accomplishments you've had in your life, and I thank you for preparing me for the life I live today!

Rand H. Morimoto, Ph.D., MBA, MCSE

I dedicate this book to my brother George and his wonderful family; Robin, Carrie, and Sophie. You were always the big brother I looked up to and that has never changed.

Michael Noel, MCSE+I, MCSA

I dedicate this book to my wife Penny. I could write a tome filled with all the reasons why. In short, you love me as I am and help me become all I wish to be.

Alex Lewis


About the Authors

Rand Morimoto has been in the computer industry for more than 25 years and has authored, coauthored, or been a contributing writer on dozens of books on Windows 2003, Exchange 2003, security, BizTalk Server, and remote and mobile computing. Rand is the President of Convergent Computing, an IT consulting firm in the San Francisco Bay Area that was one of the key early adopter program partners with Microsoft in implementing beta versions of Windows Server 2003 in production environments more than three years before the product's release. Besides speaking at more than 50 conferences and conventions around the world in the past year about tips, tricks, and best practices on planning, migrating, and implementing Windows Server 2003, Rand is also a Special Advisor to the White House on Cyber-Security and Cyber-Terrorism.

Michael Noel has been in the computer industry for more than 15 years and has been working with the latest in Windows, Exchange, and SharePoint technologies since the early versions of the software. Michael is the author of ISA Server 2004 Unleashed and the coauthor of Exchange Server 2003 Unleashed and SharePoint 2003 Unleashed from Sams Publishing, and leads WebCasts and other speaking events throughout the United States. Currently a Senior Consultant at Convergent Computing in the San Francisco Bay Area, Michael leverages his expertise in enterprise deployment and migration projects in his publications and speaking engagements.

Alex Lewis has been in the high tech industry over 10 years ranging from aerospace to gaming and is an expert in system and process security, data integrity, incident handling, and security strategy. He is a specialist in secure messaging and VPN structure including exotic designs for Fortune 500 companies and government contractors. Alex is a contributing author of Exchange Server 2003 Unleashed from Sams Publishing. He has also spoken at dozens of industry conferences including HOPE and private sessions at DEFCON. Currently a Senior Consultant at Convergent Computing in the San Francisco Bay Area, Alex uses a wide array of expertise in enterprise design and implementation in his writing and speaking engagements.


Acknowledgments

Rand H. Morimoto, Ph.D., MBA, MCSERevising this book was a lot of work, and there are many people to thank who have helped to make it a reality. We want to thank our acquisitions editor, Neil Rowe, who continues to support our efforts!

We also want to thank all the consultants, consulting engineers, technical specialists, project managers, technical editors, and systems engineers at Convergent Computing who were valuable resources we called upon for thoughts, suggestions, best practices, tips, and tricks that made up the content of this book. The only way we could create such a valuable book was to compile the experience of so many individuals living and working with Windows 2003 day in and day out.

Thank you to all of the writers, contributors, and technical editors from the first and second editions including Kenton Gardinier, Omar Droubi, Lynn Langfeld, Colin Spence, Ilya Eybelman, and Tiffany Phillips for your contribution to the initial core of this book.

Last but not least, to my two wonderful children, Kelly and Chip, thank you for being my inspiration to everything! Thank you to my parents, Ed and Vickie, for sharing with me the belief that hard work, dedication, and determination can lead to accomplishment and success. Another one done, whew!

Michael Noel, MCSE+I, MCSAA big thanks to all of the folks that made this book possible, especially Rand Morimoto, who brought me in on the first edition of this book what seems like so long ago. Thanks as well to all of the technical staff at Convergent Computing who helped to write chapters, test scenarios, and just plain and simple beat this software into submission. You guys are the best technical team I have ever been a part of!

And to my family, thanks again for putting up with yet another book. I honestly don't know how you put up with losing your husband/father/son so often! I love you Marina, you complete me! Liza and Val, you guys are wonderful! Julia, you make me smile every day!

Alex LewisThis wouldn't have been possible without unending support from my new wife, Penny. She performed the ultimate in gopher duties from coffee to massages during my writing of this book. She understood the long nights and made every sacrifice with a supportive smile. She is my rock in every way.

Also, thank you to Rand Morimoto for being a daily inspiration and the personification of the American dream. I truly appreciate your drive for success and pushing me to do the same. It has been a pleasure working on this project together. I wouldn't be the person I am today without your support and the technical hive-mind at Convergent Computing. Andrew Abbate, you embody the idyllic traits needed to be successful paired with a unique technical acuity. Thank you for your help on so many levels.

Finally, thank you to my parents, Debi and Al, for instilling a sense of independence, responsibility, and ambition. It's those lessons I learned years ago that drive me today.


We Want to Hear from You!

As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we're doing right, what we could do better, what areas you'd like to see us publish in, and any other words of wisdom you're willing to pass our way.

As an associate publisher for Sams Publishing, I welcome your comments. You can email or write me directly to let me know what you did or didn't like about this bookas well as what we can do to make our books better.

Please note that I cannot help you with technical problems related to the topic of this book. We do have a User Services group, however, where I will forward specific technical questions related to the book.

When you write, please be sure to include this book's title and author as well as your name, email address, and phone number. I will carefully review your comments and share them with the author and editors who worked on the book.

Email: | feedback@samspublishing.com
Mail: | Neil Rowe Senior Acquisitions Editor Sams Publishing 800 East 96th Street Indianapolis, IN 46240 USA

For more information about this book or another Sams Publishing title, visit our Web site at www.samspublishing.com. Type the ISBN (excluding hyphens) or the title of a book in the Search field to find the page you're looking for.


Introduction

Since its release in April 2003, the Windows Server 2003 operating system has undergone several updates and enhancements. However, unlike earlier versions of the Windows operating systems in which the updates were built into the Service Packs, with Windows Server 2003, Microsoft has released the updates as Feature Packs and most recently as the Windows 2003 R2 update. In addition to changes in how Windows 2003 would be designed, implemented, and supported with these new additions, there have been tips, tricks, and lessons learned from post-product release implementations that take advantage of these new enhancements to Windows.

When my co-authors and I set out to revise this book, we wanted to provide a fresh perspective on planning, designing, implementing, migrating, and supporting a Windows Server 2003 environment based on the latest best practices. We went through every page of this book and chose to rewrite sections in which new product features, functions, or lessons learned suggested a revision was advisable.

We found that Windows 2003 R2 was more than just a handful of new Windows components, but in many ways changed the way an organization would design, implement, and support their Windows 2003 environment now that the R2 enhancements are available. So, you'll find notes, comments, and tips throughout this third edition on the various components and tools now available in these updates.

The three of us (Rand, Mike, and Alex) have been working with Windows "Whistler" since within two weeks after Windows 2000 was released to manufacturing in December 1999. We have planned, designed, implemented, and supported hundreds, if not thousands, of implementations of Windows Server 2003. This book was written based on years of experience with Windows Server 2003.

This book is organized into 11 parts, each part focusing on core Windows Server 2003 areas, with several chapters making up each part. The parts of the book are as follows:

  • Part I: Windows Server 2003 Overview This part provides an introduction to Windows Server 2003, not only from the perspective of a general technology overview, but also to note what is truly new in Windows Server 2003 that made it compelling enough for organizations to implement the technology in beta in a production environment. We also cover basic planning, prototype testing, and migration techniques, as well as provide a full chapter on the installation of Windows Server 2003.

  • Part II: Windows Server 2003 Active Directory This part covers Active Directory planning and design. If you have already designed and implemented your Active Directory, you will likely not read through this section of the book in detail. However, you might want to look through the best practices at the end of each chapter because we highlight some of the tips and tricks new to Windows Server 2003 that are different from Windows 2000. You might find that limitations or restrictions you faced when designing and implementing Windows 2000 and Active Directory have now been revised. Topics such as domain rename, inter-forest trusts, and forest-to-forest migration capabilities might be of interest.

  • Part III: Networking Services This part covers DNS, DHCP, domain controllers, and IIS from the perspective of planning, integrating, migrating, and coexistence. Again, just like in Part II, you might find the notes, tips, and best practices to have valuable information on features that are new in Windows Server 2003; they might have you reading these chapters to understand what's new and different that you can leverage after a migration to Windows Server 2003.

  • Part IV: Security Security is on everyone's mind these days, so it was a major enhancement to Windows Server 2003. We actually dedicated four chapters of the book to security, breaking the information into server-level security such as the Encrypting File System (EFS) and Software Update server; transport-level security such as IPSec and NAT Traversal; Windows .NET Passports for single sign-on authentication; and security policies and security tools that focus on Group Policies for Active Directory security implementation and enforcement.

  • Part V: Migrating to Windows Server 2003 This part is dedicated to migrations. We provide a chapter specifically on migrating from Windows NT 4.0 to Windows Server 2003, as well as a chapter specifically on migrating from Windows 2000 to Windows Server 2003. These chapters are loaded with tips, tricks, and cautions on migration steps and best practices.

  • Part VI: Windows Server 2003 Administration and Management In this part, seven chapters focus on the administration of a Windows Server 2003 environment. This is where the importance of a newly written book (as opposed to a modified Windows 2000 book) is of value to you, the reader. The administration and management of users, domains, sites, and organizations have been greatly enhanced in Windows Server 2003. Although you can continue to perform tasks the way you did in Windows 2000, because of significant changes in replication, background transaction processing, secured communications, and management tools, there are better ways to work with Windows Server 2003. These chapters drill down into specialty areas helpful to administrators of varying levels of responsibility.

  • Part VII: Remote and Mobile Technologies Mobility is a key improvement in Windows Server 2003, so this part focuses on enhancements made to Routing and Remote Access Services (RRAS) as well as Windows Terminal Services. Instead of just providing a remote node connection, Windows Server 2003 provides true end-to-end secured anytime/anywhere access functionality. The chapters in this part highlight best practices on implementing and leveraging these technologies.

  • Part VIII: Desktop Administration Another major enhancement in Windows Server 2003 is the variety of new tools provided to support better desktop administration, so this part is focused on desktop administration. The chapters in this part go in depth on Group Policies, the Group Policy Management Console, and desktop administration tools in Windows Server 2003.

  • Part IX: Fault Tolerance Technologies As networks have become the backbone for information and communications, Windows Server 2003 must be reliable, and sure enough, Microsoft included several new enhancements in fault-tolerant technologies. The four chapters in this part address file-level fault tolerance in Distributed File System (DFS), clustering, network load balancing, backup and restore procedures, and Automated System Recovery (ASR). When these new technologies are implemented in a networking environment, an organization can truly achieve enterprise-level reliability and recoverability.

  • Part X: Problem Solving, Debugging, and Optimization This part of the book covers performance optimization, capacity analysis, logging, and debugging to help optimize and problem-solve a Windows Server 2003 networking environment.

  • Part XI: Integrated Windows Application Services Based on suggestions from book reviews and online comments, we have added a new part to this edition that covers the Feature Pack add-in Windows Sharepoint Services and the Windows Media Services component.

The chapters in this book that underwent the most significant changes since the second edition of the book include

  • Chapter 1 This chapter was revised to reference all the new capabilities built in to Windows 2003 R2 and the best practices at implementing R2.

  • Chapter 3 This chapter was revised to address the installation of the Windows 2003 service packs as well as the Windows 2003 R2 update.

  • Chapter 4 This chapter was revised to highlight all the revisions and changes made in the new Active Directory Federated Forest function introduced in Windows 2003 R2.

  • Chapter 5 This chapter was revised to address new design considerations for Active Directory Federated Forests (ADFS) and Active Directory in Application Mode (ADAM) capabilities new to Windows 2003 R2.

  • Chapter 8 This chapter underwent significant revisions to support discussions around Windows 2003 R2's Unix supportability specific to NFS, ID Mgmt for Unix, Subsystem for Unix, and SNIS.

  • Chapter 12 This chapter was revised to highlight the new security functions added to Windows 2003 R2.

  • Chapter 13 This chapter was also revised to highlight the new security functions added to Windows 2003 R2.

  • Chapter 16 This chapter was revised to highlight updated tips and tricks in migrating from Windows NT to Windows 2003 R2 that are slightly different than pre-R2 migration strategies.

  • Chapter 17 This chapter was also revised to highlight updated tips and tricks in migrating from Windows 2000 to Windows 2003 R2 that are slightly different than pre-R2 migration strategies.

  • Chapter 19 This chapter had an entire section added at the end of the chapter to cover the new Print Management Component new to Windows 2003 R2 that helps organizations better manage printers throughout the enterprise.

  • Chapter 25 This chapter was significantly updated to highlight the updates to the MOM 2005 Management Packs for Windows 2003 and the Windows 2003 R2 update.

  • Chapter 30 This chapter underwent significant revisions to address two major enhancements added to Windows 2003 R2: the File Server Resource Manager tool and the new Distributed File System Replication functionality.

  • Chapter 34 This chapter was revised to highlight the updates to Windows 2003 R2 relative to enterprise logging, as well as updates to tips and tricks in debugging Windows 2003.

  • Chapter 35 This chapter was revised to address new tips and tricks in conducting capacity analysis and performance optimization of a Windows 2003 R2 environment using new tools such as the Server Performance Analyzer tool.

  • Chapter 36 This chapter was completely revised to note the new changes in Windows SharePoint Services SP2 that was included as part of the Windows 2003 R2 update.

It is our hope that the real-world experience we have had in working with Windows Server 2003 and our commitment to revising this book to update it with current tips, tricks, and best practices has allowed us to relay to you information that will be valuable in your planning, implementation, migration, and support of a Windows Server 2003 enterprise environment.


Part I: Windows Server 2003 Overview

In This Part

CHAPTER 1 Windows Server 2003 Technology Primer

CHAPTER 2 Planning, Prototyping, Migrating, and Deploying Windows Server 2003 Best Practices

CHAPTER 3 Installing Windows Server 2003


Chapter 1. Windows Server 2003 Technology Primer

In This Chapter

  • Windows Server 2003 Defined

  • Choosing to Implement Windows Server 2003

  • When Is the Right Time to Migrate?

  • Versions of Windows Server 2003

  • What's New in Windows Server 2003?

  • Windows Server 2003 Benefits for Administration

  • Windows Server 2003 for Better User Services

  • Benefits for Thin Client Terminal Services

  • Benefits for Improved Management

  • Extending the Directory Beyond Active Directory

  • Going Beyond the Basic Features of Windows 2003 with Feature Packs

  • Extending the Capabilities of Windows 2003 with Downloadable Tools

  • Getting Started with Windows Server 2003


Windows Server 2003 Defined

More than three years after its release date, and well over five years from the time early adopters were putting it out in production environments, Windows Server 2003 has proven itself to be the most stable and reliable server operating system Microsoft has ever shipped. Many have called Windows Server 2003 a major Service Pack for Windows 2000 for the ease of the upgrades from Windows 2000 to Windows 2003. However, many consider the new security, fault tolerance, add-on tools, and overall functional improvements to be the long-awaited rewrite of the Windows operating system.

To the casual observer, Windows Server 2003 looks like nothing more than the Windows XP graphical user interface on top of the old Windows 2000 server operating system, with a few added utilities. However, now that organizations have been able to deploy Windows 2003 throughout their enterprises, when you look under the hood, Windows Server 2003 is a major rewrite of the Windows 2000 operating system, with significant changes to the kernel that makes Windows Server 2003 achieve the reliability, fault tolerance, and scalability that major organizations have been demanding of their network operating system for years.

This chapter introduces the significant enhancements and diverse capabilities of the Windows Server 2003 operating system, and references the chapters through the balance of this book that detail these improvements. The differences that Windows Server 2003 adds to a networking environment, along with best practices learned from enterprise implementation of Windows 2003, require a re-education so that design and implementation decisions made with previous versions of Windows are handled differently with Windows Server 2003 to take advantage of the enhanced operating system capabilities.

Note

This edition of Microsoft Windows Server 2003 Unleashed covers the base Windows 2003 operating system as well as the Windows 2003 R2 update. Throughout this chapter and this book, references will be made to features standard to the base configuration of Windows 2003, as well as what has been incrementally added to the Windows 2003 R2 update.

Windows .NET Framework Versus Windows Server 2003

When we're talking about Windows Server 2003, one of the first points that frequently needs to be clarified is the difference between the Windows Server 2003 operating system and the Windows .NET Framework. These two terms are frequently (and improperly) used interchangeably; however, they are completely different.

The Windows .NET Framework was announced first, formally during the summer of 2001, in reference to a completely new application development environment by Microsoft. When we refer to Windows Server 2003, it is an actual network operating system product in which software is installed on a server and applications are executed. Windows Server 2003 is a part of the Windows .NET Framework.

Understanding the Windows .NET Framework

The Windows .NET Framework is the application development environment in which a common language runtime, framework classes, and an application development process are defined. Until the introduction of the Windows .NET Framework, some organizations developed applications using Visual Basic; some organizations, using Visual C; some organizations, using Active Server Pages technology for a Web server; and some organizations, using an Open Database Connectivity (ODBC) front-end application to Microsoft SQL or Microsoft Access.

Now with the Windows .NET Framework, a default programming model called ASP.NET is defined. ASP.NET makes building real-world Web applications much easier. It has a series of built-in framework classes that allow a developer to call a built-in application function instead of having to code the function line by line. This capability greatly minimizes the amount of programming necessary to create a Web application similar to those created in the past.

ASP.NET does not require any single application development tool; in fact, it supports dozens of standard programming languages available today, such as VBScript, JScript, Visual Basic .NET, C#, Visual Basic, and the like.

Other significant improvements in ASP.NET include a dynamic code compilation that automatically detects changes and compiles the code so that it is ready to run at any time. The Windows .NET Framework is a distributed application environment allowing for code to be distributed across multiple systems within a Web farm.

In addition, to deploy a Windows .NET Framework application for access within an organization or to the general public, all the developer needs to do is copy the files to a Windows .NET Framework server. There is no need to run regsrv32 to register components on the server because configuration settings are stored in an XML data file within the application.

For organizations looking to develop Web-based applications, the Windows .NET Framework greatly simplifies application development. The Windows .NET Framework has created a powerful development environment that has a series of built-in routines that decrease application coding time and effort, while providing the support for existing standards for application programming languages.

As server add-ons are created for a Windows Server 2003 environment, such as Outlook Web Access for Exchange 2003 and SharePoint 2003, or even add-on tools like the Directory Services Mark-up Language (DSML), the .NET Framework is leveraged more and more in developing core applications and Feature Packs.

Understanding the Core Windows Server 2003 Operating System

Whereas the Windows .NET Framework is the set of tools and technologies used for application development, the Windows Server 2003 product is a full network operating system. As a traditional network operating system, Windows Server 2003 can serve in the following roles:

  • File and print server As a file and print server, the Windows Server 2003 system can provide network users with centralized access to data files or can act as a print queue server to host multiple printers. Several improvements have been made in Windows Server 2003 for file security (covered in Chapter 12, "Server-Level Security"), file server fault tolerance (covered in Chapter 30, "File System Fault Tolerance"), and the configuration of redundant print services (covered in Chapter 3, "Installing Windows Server 2003").

  • Web server In Windows Server 2003, Web servers take on a much more expanded role than they did with early Windows NT or even Windows 2000 Web environments. Rather than just hosting static HTML Web pages, Windows Server 2003 participates in Web farms that distribute dynamic Web content with network load balancing (covered in Chapter 31, "System-Level Fault Tolerance [Clustering/Network Load Balancing]").

  • Application server With the release of the Windows Server 2003 operating system, ongoing updates to the applications that run on the Windows Server 2003 system will be released regularly. Some of the applications that come with Windows Server 2003 include Windows Terminal Services for thin client computing access (covered in Chapter 27, "Terminal Services"), Windows Media Server for video and audio hosting and broadcasting (covered in Chapter 37, "Windows Media Services"), and utility server services such as DNS and DHCP (covered in Chapters 9, "Domain Name System," and 10, "DHCP/WINS/Domain Controllers"). Add-ons to Windows Server 2003 include Windows Server 2003 editions of Microsoft Exchange Server 2003, SharePoint Portal Server 2003, BizTalk Server 2004, and ISA Server 2004.

  • Windows .NET application host New to Windows Server 2003 is the capability for the server to act as a host system for the execution of Windows .NET Framework applications. With built-in Internet Information Server version 6 (covered in Chapter 11, "Internet Information Services"), Windows .NET applications can be copied straight to the Windows Server 2003 for execution.

This book focuses on the Windows Server 2003 operating system and the planning, migration, security, administration, and support of the operating system. Windows Server 2003 is also the base network operating system on top of which all future Windows server applications will be built.


Choosing to Implement Windows Server 2003

Windows Server 2003 is a versatile operating system, one that meets the needs of various business functions. Like earlier network operating systems such as Novell NetWare or Windows NT that were known best for file/print servers, Windows Server 2003 can provide all that functionality and a lot more.

Because Windows Server 2003 provides many different functions, an organization needs to choose how to best implement Windows Server 2003 and the various networking features that meet its needs. In small network environments with fewer than 20 to 30 users, an organization may choose to implement all the Windows Server 2003 features on a single server. However, in larger environments, multiple servers may be implemented to improve system performance as well as provide fault tolerance and redundancy.

As mentioned in the preceding section, Windows Server 2003 can act as the core operating system to host applications such as utility services, file services, print services, or Web-based services. Some of the other major networking services provided by Windows Server 2003 include running the operating system as the core to an Active Directory environment, as a built-in Windows application server, or as an add-on application server.

Windows Server 2003 Core to an Active Directory Environment

One of the major additions to the network operating system role introduced with the release of the Windows 2000 operating system was the Active Directory. Active Directory is more than a simple list of users and passwords for authentication into a network, but rather a directory that extends to other business applications. When fully leveraged, an organization can have its Human Resources (HR) department add an employee to the organization's HR software. The HR software automatically creates a user in the Active Directory, generating a network logon, an email account, a voicemail account, and remote access capabilities, and then links pager and mobile phone information to the employee. Likewise, if an employee is terminated, a single change in the HR software can issue automated commands to disable the individual's network, email, remote logon, and other network functions.

Windows Server 2003 extends the capabilities of the Active Directory by creating better management tools, provides for more robust directory replication across a global enterprise, and allows for better scalability and redundancy to improve directory operations. Windows Server 2003 effectively adds in more reliability, faster performance, and better management tools to a system that can be leveraged as a true enterprise directory provisioning, resource tracking, and resource management tool. Because of the importance of the Active Directory to the Windows Server 2003 operating system, plus the breadth of capabilities that Active Directory can facilitate, five chapters in Part II of this book are dedicated to Active Directory.

Windows Server 2003 Running Built-in Application Server Functions

Windows Server 2003 comes with several programs and utilities to provide robust networking capabilities. In addition to the basic file and print capabilities covered earlier in this chapter, Windows Server 2003 can provide name resolution for the network and enable high availability through clustering and fault tolerance, mobile communications for dial-up and virtual private network connections, Web services functions, and dozens of other application server functions.

When planning the implementation of Windows Server 2003, a network architect needs to consider which of the server services are desired, how they will be combined on servers, and how they will be made redundant across multiple servers for business continuity failover. For a small organization, the choice to combine several server functions to a single system or to just a few systems is one of economics. However, an organization might distribute server services to multiple servers to improve performance (covered in Chapter 35, "Capacity Analysis and Performance Optimization"), distribute administration (covered in Chapter 19, "Windows Server 2003 Administration"), create redundancy (covered in Chapter 33, "Recovering from a Disaster"), enable security (covered in Chapter 12), or to service users across a diverse geographic area (covered in Chapter 5, "Designing a Windows Server 2003 Active Directory").

Some of the built-in application server functions in Windows Server 2003 include the following:

  • Domain controller Like in previous versions of the Microsoft Windows operating system, the domain controller allows users to authenticate to the server for access to network resources.

  • Global catalog server The global catalog server stores a copy of the user list of the Active Directory network. When an internal or external user with appropriate security rights wants to look at a list of Active Directory users, the global catalog server provides the list.

  • DNS server The domain name service (DNS) is a list of network servers and systems, so a DNS server provides information about the devices connected to the network.

  • DHCP server The Dynamic Host Configuration Protocol (DHCP) assigns network addresses to devices on the network. Windows Server 2003 provides the service function to facilitate DHCP addresses to network devices.

  • Cluster server When fault tolerance is important to an organization, clustering provides failover from one system to another. Windows Server 2003 provides the ability to link systems together so that when one system fails, another system takes over.

  • Terminal server Instead of having a full desktop or laptop computer for each user on the network, organizations have the option of setting up simple, low-cost terminals for users to gain access to network resources. Windows Server 2003 Terminal Services allows a single server to host network system access for dozens of users.

  • Remote access server When a remote user has a desktop or laptop system and needs access to network services, Windows Server 2003 provides remote access services that allow the remote systems to establish a secure remote connection.

  • Web server As more and more technologies become Web-aware and are hosted on Web servers, Windows Server 2003 provides the technology to host these applications for browser-based access.

  • Media server With information extending beyond text-based word processing documents and spreadsheets into rich media such as video and audio, Windows Server 2003 provides a source for hosting and publishing video and audio content.

  • Distributed File System (DFS) server For the past decade, data files have been stored on file servers all around an organization. Windows Server 2003 provides Distributed File Systems that allow an organization to take control of distributed files into a common lookup file directory.

These plus several other functions provide robust networking services that help organizations leverage the Windows Server 2003 technologies into solutions that solve business needs.

Windows Server 2003 Running Add-in Applications Server Functions

In addition to the built-in server application functions such as DNS, DHCP, Global Catalog, Terminal Services, and the like noted in the preceding section, Windows Server 2003 also provides the basis from which add-in applications can be purchased and implemented on the Windows servers. Some of these add-in applications come from Microsoft, such as the Windows Server 2003 versions of the Microsoft Exchange messaging system or Microsoft SQL database system. Other add-ins to Windows Server 2003 are furnished by companies that provide human resource management applications; accounting software; document management tools; fax or voicemail add-ins; or other business, industry, or user productivity capabilities.

In earlier Windows server operating systems, the core operating system provided simple logon and network connectivity functions; however, with Windows Server 2003, the operating system includes many core capabilities built into the Windows Server 2003 operating environment. With integrated fault tolerance, data recovery, server security, remote access connectivity, Web access technologies, and similar capabilities, organizations creating add-ins to Windows Server 2003 can focus on business functions and capabilities, not on core infrastructure reliability, security, and mobile access functionality. This offloading of the requirement of third-party add-in organizations to implement basic networking technologies into their applications allows these developers to focus on improving the business productivity and functionality of their applications. Additionally, consolidating information routing, security, remote management, and the like into the core operating system provides a common method of communication, authentication, and access to users without having to load up special drivers, add-ins, or tools to support each and every new application.

Much of the shift from application-focused infrastructure components to core operating system-focused functionality was built into Windows 2000. There were many challenges when Windows 2000 was first released because of this shift in product functionality; however, after being on the market for more than three years, Windows 2000 add-ins and now Windows Server 2003 add-ins have had several revisions to work through system functionality and component reliability between application and operating system. Fortunately, Windows Server 2003 uses the same application/operating system technology used in Windows 2000, so applications written for Windows 2000 typically need just a simple Service Pack update to be able to run on Windows Server 2003.


When Is the Right Time to Migrate?

When Windows Server 2003 first shipped during the Spring of 2003, many organizations wondered about the right time to migrate to the new operating system. It used to be that you waited until the first Service Pack shipped before installing any Microsoft product; however, Windows 2003 surprised a lot of organizations by being extremely reliable and actually more dependable than patched versions of Windows NT4 and Windows 2000. So, the end result decision came down to the same decision on migration to any new technologyidentify the value of migrating versus the cost and effort to migrate.

This introductory chapter notes the many features and functions built into Windows Server 2003 that have helped other organizations make the decision that Windows Server 2003 has significant value to plan a migration. Improvements in security, performance, and manageability provide benefits to organizations looking to minimize administration costs, while providing more functionality to users.

The cost and effort to migrate to Windows Server 2003 vary based on the current state of an organization's networking environment as well as the Windows Server 2003 features and functions the organization wants to implement. Some organizations begin their migration process to Windows Server 2003 by adding a Windows Server 2003 into an existing Windows NT4 or Windows 2000 network, migrating from Windows 2000 to Windows Server 2003, and migrating from Windows NT4 to Windows Server 2003.

Adding a Windows Server 2003 to an NT4 or Windows 2000 Environment

Many organizations want to add in a specific Windows Server 2003 function such as Windows Server 2003 Terminal Services, Windows Server 2003 Remote Access Services, Windows Server 2003 Media Services, or the like. Such functions can be added on Windows Server 2003 member servers in existing Windows NT4 or Windows 2000 networking environments. This allows an organization to get Windows Server 2003 application capabilities fairly quickly and easily without having to do a full migration to Windows Server 2003. In many cases, a Windows Server 2003 member server can simply be added to an existing network without ever affecting the existing network. This addition provides extremely low network impact but enables an organization to prototype and test the new technology, pilot it for a handful of users, and slowly roll out the technology to the client base as part of a regular system replacement or upgrade process.

Some organizations have replaced all their member servers to Windows Server 2003 systems over a period of weeks or months as a preparatory step to eventually migrate to a Windows Server 2003 Active Directory structure.

Migrating from Windows 2000 to Windows Server 2003

For organizations that have already migrated to Windows 2000 and the Active Directory environment, migrating to Windows Server 2003 for Active Directory functionality can provide access to several additional capabilities that require a Windows network to be running on Windows Server 2003. Some of the Windows Server 2003 technologies that require implementation of the Windows Server 2003 Active Directory include RIS for Servers, Windows Server 2003 group policy enhancements, and the full Windows Server 2003 Distributed File System.

Fortunately, organizations that have already implemented Windows 2000 or have already migrated from Windows NT4 to Windows 2000 have completed the hard part of their migration process. Effectively, Windows Server 2003 uses the same Active Directory organizational structure that was created with Windows 2000, so forests, domain trees, domains, organizational users, sites, groups, and users all transfer directly into Windows Server 2003. If the organizational structure in Windows 2000 met the needs of the organization, the migration to Windows Server 2003 is predominantly just the insertion of a Windows Server 2003 global catalog server into the existing Windows 2000 Active Directory domain to perform a global catalog update from Windows 2000 Active Directory to Windows 2003 Active Directory.

Unlike the migration process from Windows NT4 to Windows 2000, in which an organization was unable to migrate a Windows NT4 backup domain controller (BDC) to a Windows 2000 domain controller (DC), Windows Server 2003 enables an organization to migrate its Windows 2000 DCs to Windows Server 2003 DCs, thus allowing an interim mode for partial (slower) migration to Windows Server 2003.

Of course, planning, system backup, and prototype testingcovered in Chapter 17, "Migrating from Windows 2000 to Windows Server 2003"help minimize migration risks and errors and lead to a more successful migration process. However, the migration process from Windows 2000 to Windows Server 2003 is a relatively easy migration path for organizations to follow.

Many organizations choose to make changes in their Active Directory structure when they migrate from Windows 2000 to Windows Server 2003, such as changing simple domain structure or possibly even doing a complete domain rename. Windows Server 2003 provides several tools, covered in Chapter 17, that help organizations make changes to their Active Directory during their migration process. Many of these processes can be completed before migrating to Windows Server 2003, but many of them can be completed after migrating to Windows Server 2003 as well. And several of these processes are best completed during the migration of Windows Server 2003. Therefore, it is important to plan any changes and review Chapter 17 before starting a migration.

Migrating Directly from Windows NT4 to Windows Server 2003

Organizations that still have Windows NT4 in their networking environments must decide whether to migrate from Windows NT4 to Windows 2000, or to migrate directly from Windows NT4 to Windows Server 2003. Some of the deciding factors are determining what Windows Server 2003 features and functions they want and the cost and effort to migrate. As noted earlier in the section "When Is the Right Time to Migrate?", organizations do not necessarily have to migrate completely to Windows Server 2003 to get its functionality. They can choose to migrate just a couple of member servers from Windows NT4 to Windows Server 2003 without having to migrate the whole Active Directory domain structure. This can be a first step in getting Windows Server 2003 technology into their network.

If an organization has already begun its migration to Windows 2000, it might choose to shift to an implementation of future global catalog servers as Windows 2003 systems. A huge benefit of a shift from Windows 2000 Active Directory to Windows 2003 Active Directory is the ability to easily intermix global catalog servers. New global catalog servers can be Windows 2003 systems, and existing Windows 2000 global catalog servers can remain until such time as it is convenient to upgrade those servers to Windows 2003. Of course, an organization can choose to migrate completely from Windows NT4 to Windows Server 2003, and because the forest, domain, site, and other structural functions of Windows 2000 and Windows Server 2003 are identical, any planning done for a migration to Windows 2000 can be applied to an organization's decision to migrate from Windows NT4 to Windows Server 2003.

The planning, design, prototype, and migration steps to assist an organization in its migration from a Windows NT4 to a Windows Server 2003 environment are covered in Chapter 16, "Migrating from NT4 to Windows Server 2003."


Versions of Windows Server 2003

With the release of Windows Server 2003, a change in the various versions of the operating system was announced. Rather than just Server and Advanced Server editions of the operating system, there are four different Windows Server 2003 editions: the basic Web edition, a Standard edition, an Enterprise edition, a Datacenter edition, and editions that support 64-bit processors.

Windows Server 2003 Web Edition

The Windows Server 2003 Web edition is a one- to two-processor Web front-end server version of the operating system focused on application server needs that are dedicated to Web services needs. Many organizations are setting up simple Web servers as front ends to database servers, messaging servers, or data application server systems. Windows Server 2003 Web edition can be used as a simple Web server to host application development environments or can be integrated as part of a more sophisticated Web farm and Web Services environment that scales to multiple load-balanced systems. The Windows Server 2003 operating system has significant improvements in scalability over previous versions of the Windows operating system, and an organization can license multiple Web services systems at a lower cost per server to provide the scalability and redundancy desired in large Web farm environments.

Windows Server 2003 Web edition supports up to 2GB of RAM for front-end Web cache capabilities.

Note

For organizations looking to purchase the Windows Server 2003 Web edition to set up as a very low cost file and print server or utility server (DNS, DHCP, domain controller), the Web edition does not provide traditional multiuser file or print access or utility services. You need to purchase the Windows Server 2003 Standard edition to get capabilities other than Web services.

Windows Server 2003 Standard Edition

The Windows Server 2003 Standard edition is the most common "file server" version of the operating system. The Standard edition supports up to four processors per server, has full support for file and print services functions, can act as a multiprocessor Web server, supports Terminal Services, provides Media Services, can be set up as a utility server, and can support up to 4GB of RAM.

The Standard edition is a good version of the operating system to support domain controllers, utility servers (such as DNS, DHCP, bridgehead servers), file servers, and print server services. Many small and medium-size organizations find the capabilities of the Standard edition sufficient for most network services, and even large organizations use the Standard edition for utility servers or as the primary server in a remote office. Effectively, any environment in which a system with one to four processors is sufficient can meet the needs of the server functions. See Chapter 35 for capacity analysis and server scalability recommendations for a Windows Server 2003 system.

Windows Server 2003 Enterprise Edition

The Windows Server 2003 Enterprise edition is focused on server systems that require up to eight processors and/or up to 8-node clustering for large scale-up server configurations. With support for up to 32GB of RAM as well as a 64-bit Itanium version available, the Enterprise edition is the appropriate version of operating system for high availability and high processing demands of core application servers such as SQL Servers or large e-commerce back-end transaction systems.

For organizations leveraging the capabilities of Windows Server 2003 for Thin Client Terminal Services that require access to large sets of RAM and multiple processors, the Enterprise edition can handle hundreds of users on a single server. Terminal Services are covered in more detail in Chapter 27.

The Enterprise edition, with support for up to 8-node clustering, can provide organizations with the nonstop networking demands of true 24x7, 99.999% uptime capabilities required in high-availability environments. Windows Server 2003 Enterprise edition supports a wide variety of regularly available server systems, thus allowing an organization its choice of hardware vendor systems to host its Windows Server 2003 application needs.

A handful of services that are available on the Enterprise edition of Windows Server 2003 but not on the Standard edition include the capability to support the Microsoft Identity and Integration Server synchronization, Windows Terminal Server session directory, Windows remote storage functionality, and Windows System Resource Manager. If this functionality is required, the Enterprise Edition needs to be selected as the server option.

Windows Server 2003 Datacenter Edition

Windows Server 2003 Datacenter edition is a proprietary hardware version of the operating system that supports from 8 to 64 processors and up to 8-node clustering. The Datacenter edition is focused on organizations that need scale-up server technology to support a large centralized data warehouse on one or limited numbers of server clusters.

As noted in Chapter 35 on performance and capacity analysis, an organization can scale-out or scale-up its server applications. Scale-out refers to an application that performs better when it is distributed across multiple servers, whereas scale-up refers to an application that performs better when more processors are added to a single system. Typical scale-out applications include Web server services, electronic messaging systems, and file and print servers. In those cases, organizations are better off distributing the application server functions to multiple Windows Server 2003 systems. However, applications that scale-up, such as e-commerce or data warehousing applications, benefit from having all the data and processing on a single server cluster. For these applications, Windows Server 2003 Datacenter edition provides better centralized scaled performance as well as the added benefit of fault tolerance and failover capabilities.

With the Datacenter edition's support for up to 8-node clustering, an organization can share the processing power of 8x64 processors per server to gain transactions per second that exceed the capabilities of many mainframe and mini-computer technology systems.

In addition to scale-up capabilities of clustering, an organization can create failover between clustered systems to achieve 99.999% uptime levels.

Note

The Windows Server 2003 Datacenter edition is sold only with proprietary hardware systems, so an organization cannot buy the Datacenter edition software and build or configure its own 32-way multiprocessor system. The Datacenter edition is developed and tested by a consortium of hardware vendors to strict standards for performance, reliability, and supportability.

Windows Server 2003 x64-bit Edition

In 2005, Microsoft shipped an x64-bit edition of the Windows 2003 operating system to support 64-bit processors. The x64-bit version of Windows 2003 provides support for more memory access and faster server performance that ultimately increases the scalability capabilities of the Windows networking environment.

Note

This book does not address x64-bit Windows separately. Because x64-bit Windows is configured, updated, and managed just like the 32-bit Windows, this book makes no distinction between an x64-bit system and a 32-bit system.


What's New in Windows Server 2003?

From a Microsoft marketing perspective, Windows Server 2003 could be said to be faster, more secure, more reliable, and easier to manage. And it is true that the Windows Server 2003 operating system has all these capabilities. However, this section notes specifically which changes are cosmetic changes compared to previous Windows operating systems and which changes truly improve the overall administrative and end-user experience due to improvements in the operating system.

Visual Changes in Windows Server 2003

The first thing you notice when Windows Server 2003 boots up is the new Windows XPlike graphical user interface (GUI). This is obviously a simple cosmetic change to standardize the current look and feel of the Windows operating systems. Just like with Windows XP, a user can switch the new Windows GUI to look like the classic mode, and because most administrators have worked with Windows NT and Windows 2000 for a long time, they tend to switch off the XP GUI and configure the system to look like the classic version. It makes no difference whether the new GUI or the classic GUI is enabled; all the features and functions of the Windows Server 2003 operating system are the same in either mode.

Customization and Programmability of the .NET Server Interface

One of the benefits of the new Windows Server 2003 operating system is the customization and programmability of the operating system interface. Because Windows Server 2003 enables organizations to change the interface that is viewed by users of the server systems, organizations have been able to customize the GUI to provide a simple administrative interface. As an example, many organizations that have operations that support personnel providing administrative assistance at night for system backup, maintenance, or extended-hours support might prefer to customize the desktop for the late-night specialists. Rather than teaching the operations personnel specialized Windows administrative tools, they can program a simple interface in XML with scripts tied to the buttons that clear print queues, restart system services, add or disable user accounts, or back up and restore data information, for example. Chapter 23, "Automating Tasks Using Windows Server 2003 Scripting," addresses tasks that can be automated using scripts for customized user configurations.

Changes That Simplify Tasks

Windows Server 2003 has added several new capabilities that simplify tasks. These capabilities could appear to be simply cosmetic changes; however, they actually provide significant benefits for administrative management. Some of the improvements include drag-and-drop capabilities in the administrative tools and built-in configuration and management wizards.

Drag-and-Drop Capabilities in Administrative Tools

Many of the new administrative tools with Windows Server 2003 provide drag-and-drop capabilities that allow administrators to simply select objects with a mouse and drag and drop them to a new location. In Windows 2000, an administrator had to select the objects, right-click the mouse, select Move, and choose the destination from a menu or graphical tree. Although this task might seem trivial, for any administrator reorganizing users between organizational units in the Windows 2000 Active Directory Users and Computers utility, the ability to drag and drop objects can greatly simplify the time and effort required to organize and manage the Active Directory.

Built-in Setup, Configuration, and Management Wizards

Another major addition to Windows Server 2003 that simplifies tasks is a series of configuration and management wizards that come built into the operating system. Instead of an administrator having to walk through menus of commands to manually create or modify networking roles, Windows Server 2003 provides wizards that enable the administrator to add, modify, and remove system configurations. No doubt these wizards are a significant benefit to operating system novices because the questions in the wizards are typically simple to answer. However, even Windows experts prefer the wizards over manual installation tasks because it is frequently easier and faster to answer a few questions and press the Return key than it is to fumble through a series of menus, property screens, and configuration tabs entering in the same information.

Improved Security

Significantly more than just cosmetic updates are the security enhancements added to Windows Server 2003. During the middle of the development of the Windows Server 2003 product, Microsoft launched its Trustworthy Computing Initiative, which stipulated that all products and solutions from Microsoft meet very stringent requirements for security. So, although Windows Server 2003 was slated to have several new security enhancements, Trustworthy Computing created an environment in which the Windows Server 2003 product would be the most secured Windows operating system shipped to date.

Part IV of this book is focused on security in various different core areas. Chapter 12 addresses server-level security, which, from a Windows Server 2003 perspective, addresses some of the new defaults where most services are disabled on installation and must be enabled for access. Although this change might seem trivial in Windows operating system development, it provides a relatively secured server directly from initial installation. In previous versions of the Windows operating system, going through all the unneeded features of Windows and disabling the functionality to lock down a server system could easily take an hour. The server defaults as well as the functional or operational differences are also noted in Chapter 12.

IPSec and Wireless Security Improvements

Transport-level security in the form of IPSec was included in Windows 2000, but organizations have been slow to adopt this type of security typically due to a lack of understanding how it works. Chapter 13, "Transport-Level Security," addresses best practices in the way IPSec is enabled in organizations that provide a high level of server-to-server, site-to-site, and remote usertoLAN secured communications. Also covered in Chapter 13 is the new secured wireless LAN (802.1X) technology that is built into Windows Server 2003. Windows Server 2003 includes dynamic key determination for improvements in wireless security over the more common Wired Equivalency Protocol (WEP) that is used with standard 802.11 wireless communications. By improving the encryption on wireless communications, an organization can increase its confidence that Windows Server 2003 can provide a truly secured networking environment.

Microsoft Passport Support

New to Windows Server 2003 is Microsoft Passport support for logon authentication. Microsoft Passports, first introduced in the Windows XP desktop operating system, allowed desktop users to create secured communications with Passport-enabled services. The initial Passport-enabled services included instant messaging, access to certain Web sites, and Passport-enabled e-commerce sites. With the inclusion of Microsoft Passport support on Windows Server 2003, a Passport-enabled client can now log on using secured credentials to a Windows Server 2003 network. Therefore, the same Passport that allows a user to access e-commerce sites, Web sites, and instant messaging allows the user to create a secured connection to the Windows Server 2003 environment. Microsoft Passport support in a Windows Server 2003 environment is covered in detail in Chapter 14, "Windows Server 2003 Passports."

Performance and Functionality Improvements

A network end user would likely never notice many new features added to Windows Server 2003, and in many cases a network administrator would not even be aware that the technologies were updated and improved. These technologies help the network operate more efficiently and effectively, so a user might experience faster network performance. However, even if the network was able to respond twice as fast, a process that used to take three seconds to complete and now takes less than two seconds to complete is not something a user would particularly notice. The key benefit typically comes in the area of overall network bandwidth demand improvements, or for very large organizations, the performance improvements require the organization to add additional servers, processors, and site connections to scale an enterprise with systems.

Global Catalog Caching on a Domain Controller

One of the significant back-end improvements to Windows Server 2003 is the server's capability to cache global catalog information on domain controllers. In a Windows 2000 environment, for users to access the global catalog to view mail accounts and distribution lists, an organization typically put a global catalog server out to every site within the organization. This distributed global catalog server function minimized the ongoing traffic of users querying the catalog over a WAN connection every time they wanted to send an email to someone else in the organization; however, it meant that directory replication occurred to global catalogs in the enterprise to keep the directory synchronized. With Windows Server 2003, an organization can place just a domain controller in a remote location, and the global catalog information is cached to the remote system. This provides the best of both worlds where the caching of the global catalog means that the directory information is readily available to remote users, but because it is just a cache of the information and not a fully replicated copy, synchronization and distribution of catalog information are done only when initially requested, and not each time a change is made to the directory.

Fine-Tuning on Global Catalog Synchronization

Another behind-the-scenes update to Windows Server 2003 is the fine-tuning done to the way global catalog full syncs are conducted. A global catalog full sync occurs when the entire global catalog is replicated from global catalog server to global catalog server. In organizations with very large global catalogs, this replication could duplicate several megabytes of information to every global catalog server in the network, which could have a significant impact on overall network performance.

In Windows 2000, global catalog full syncs were conducted any time attributes were added to partial attribute sets (PAS). In simplified terms, this meant that if an organization had a distribution list with 5,000 names on it and the administrator added just one more name to the list, all 5,001 names were replicated from global catalog to global catalog.

With Windows Server 2003, changes can be made to partial attribute sets with only the modified attribute replicated to global catalog servers throughout the organization. This allows administrators to add a 5,001st name to a distribution list with only that single name replicated across the WAN. Similar partial replication is conducted on several other Windows Server 2003 infrastructure objects and are highlighted in Chapter 7, "Active Directory Infrastructure."

Ability to Disable Compression on High-Speed Links

Another component that users almost never realize after a migration to Windows Server 2003, but of significance to server administrators, is the ability to disable compression on high-speed links between global catalog servers. In Windows 2000, before information was replicated between servers, the information was first compressed. This compression saved on server-to-server LAN or WAN traffic bandwidth, but Windows 2000 servers were affected by increased CPU utilization when the information had to be compressed and then uncompressed when data was replicated between servers.

With Windows Server 2003, an administrator can disable the compression process, thus allowing information to replicate server to server natively. Although this replication might take up LAN or WAN bandwidth, network administrators with very high speed 100 megabit or gigabit backbones with plenty of bandwidth might prefer to use underutilized LAN/WAN bandwidth than to take up CPU utilization during the middle of the day. This function, by itself, is rarely noticed by users, but combined with several other performance-improving functions in Windows Server 2003, an organization can use it to improve overall network performance in its enterprise.

The capability to tune and optimize compression links and other networking factors is covered in Chapter 7 on the Active Directory infrastructure as well as in Chapter 35 on performance tuning and optimization.

Increased Support for Standards

The release of Windows Server 2003 introduced several industry standards built into the Windows operating system. These changes continue a trend of the Windows operating system supporting industry standards rather than proprietary Microsoft standards. Some of the key standards built into Windows Server 2003 include IPv6, XML Web services, and IETF security standards.

Support for IPv6

Windows Server 2003 supports Internet Protocol version 6 (or IPv6), which is the future Internet standard for TCP/IP addressing. Most organizations support Internet Protocol version 4 (or IPv4). Due to the Internet numbering scheme running out of address space in its current implementation of addressing, Internet communications of the future need to support IPv6, which provides a more robust address space.

Additionally, IPv6 supports new standards in dynamic addressing and Internet Protocol Security (IPSec). Part of IPv6 is to have support for the current IPv4 standards so that dual addressing is possible. With Windows Server 2003 supporting IPv6, an organization can choose to implement a dual IPv6 and IPv4 standard to prepare for Internet communications support in the future. IPv6 is covered in more detail in Chapter 7.

Support for XML Web Services

Windows Server 2003 supports XML Web services, which is the XML development language and Web services provider environment that allows for dynamic Web services in a networking environment. Web services has become the focus of all the main network operating systems, allowing server systems to host Web-based applications. XML has become a standard application development language for organizations to create applications. XML is used as the programming language driving the front end for wireless telephones, voice-over IP telephones, appliance workstations and server systems, routers, and other network devices.

XML Web services combines the expanding support for the XML development language with the growing market demand and use of Web servers, thus creating XML Web services systems. Microsoft's support for XML Web services keeps it among the organizations leveraging the latest in Web server technology.

Support for IETF Security Standards

Windows Server 2003 now supports Internet Engineering Task Force (IETF) security standards. The IETF stipulates standards for communications, protocols, and security. In the past, Microsoft created its own standards for security and rarely supported protocols for Internet security. With an initiative to support IETF standards, Microsoft can address security from an enterprise organization basis.

Ability to Delete Active Directory Schema Objects

New to Windows Server 2003 is the ability for administrators to delete Active Directory schema objects. With the introduction of the Windows 2000 Active Directory, organizations could extend the schema and make changes to the directory. However, although the schema could be extended, there were no provisions to delete objects created in the schema.

With Windows Server 2003, a schema administrator now can choose and delete Active Directory schema objects. This deletion capability now enables an organization to make changes to the schema without fear of creating schema changes that cannot be deleted in the future.


Windows Server 2003 Benefits for Administration

Windows Server 2003 provides several new benefits that help organizations better administer their networking environment. These new features provide better data and printer management, improvements in the ability to recover data for accidentally deleted files, the ability to create domain controllers from disc media, and better security support to mobile communications for mobile users.

File Server Resource Manager (FSRM)

In the Windows 2003 R2 update, Microsoft added a new component called File Server Resource Manager, or FSRM. FSRM provides an improved method of managing files stored on servers through the implementation of quota management and automatic data management. FSRM not only allows an organization to set quotas on the amount of disk space a user can use to store files, but it also enables the administrators of the network to specifically allow or limit the storage of certain file types on a server.

As an example, an organization can elect to provide all users the ability to save up to 100 megabytes of files on the main fileserver. In addition, the organization can set a policy that prevents users from storing MP3 audio files or MPG movie files on the network. FSRM can be extended even further by allowing some users more storage privileges and some users fewer storage privileges. This granular approach to storage and data management allows the administrators of the organization to better define acceptable storage and use rights to shared network resources, as well as log, track, and manage the storage of information on servers throughout the environment.

FSRM is covered in Chapter 19.

Print Management Console (PMC)

Another addition to Windows 2003 added with the Windows 2003 R2 update is the Print Management Console component, or PMC. PMC enables the administrators of the network to track, manage, and administer printers throughout the forest from a single view interface. Before PMC, the administrators had to manage printers by print queue servers. By querying a specific print queue server, the administrator was able to see all the printers connected to that print queue server. If the organization had dozens of print queue servers, the administrator would literally have to connect individually to each print queue server to query the server about the printers it was managing. This made the scalability of managing printers very difficult.

PMC combines all the printers and print queues in the forest into a single interface. From a single view, the administrators can view printers throughout the enterprise, determine which printers are not working, and address enterprisewide the management and maintenance of the printers.

PMC is covered in Chapter 19.

Volume Shadow Copy

A significant addition to Windows Server 2003 is the Volume Shadow Copy function. Volume Shadow Copy takes a snapshot of a network volume and places the copy onto a different volume on the network. After a mirrored snapshot is taken, at any time, files from the read-only shadow can be accessed without complications typical of network volumes that are in use. Volume Shadow Copy will no doubt have a variety of third-party add-ins that support access to the read-only shadow copy of information. Two of the major initial capabilities include online backup of open files and user-level retrieval of file copies. Both of these capabilities are covered in more detail in Chapter 30.

Online Backup of Open Files

The ability to back up open files has always been a challenge for organizations. Old tape backup software skipped files in use because there was no easy way to back up the files being used by network users. Improvements in tape backup software now allow an organization to enable an open file's agent on a server so that files in use can be backed up. However, the process of backing up open files either significantly slows down the normal access to files, or the files are backed up out of sequence, making restoration of the files a challenge.

Windows Server 2003 Volume Shadow Copy allows the primary network volume to be locked and a snapshot created to another volume. With the read-only shadow volume available, tape backup software can launch a backup of the files without having to contend with file access of other applications or devices. Furthermore, because the files are not in use, the backup system does not have to stop, unlock a file, back up the file, and then relock the file for user access. And because the volume shadow can reside on a different server volume or even on a different server, the information can be backed up with no impact on users.

User-Level Retrieval of Archived File Copies

Another popular use of Volume Shadow Copy is the ability for users to easily restore files they might have accidentally deleted. With Windows NT4 or Windows 2000, when a user accidentally deleted a file, if the file did not end up in the user's personal Recycle Bin, the file was effectively lost. The best the organization could typically do was recover the file from tape.

With Windows Server 2003's Volume Shadow Copy, a shadow of files can be taken periodically. Now when users want to recover an accidentally deleted file, all they have to do is access the volume shadow to select an archived file for retrieval. This Volume Shadow Copy retrieval process is also preferred over backup systems because most data file loss is caused by accidental overwriting of files or file corruption. Volume Shadow Copy can provide the online restoration of files from the last series of Windows Server 2003 snapshots.

Global Catalog Build from Media

Organizations that built global catalog servers across a fairly distributed WAN infrastructure with Windows 2000 found it very challenging because of the time required to replicate an initial global catalog over a WAN. Windows Server 2003 enables the organization to export the global catalog to a file that can be burned to CD-ROM and later used to build a global catalog server remotely.

When a remote administrator needs to build a global catalog server and runs the DCPromo utility, the administrator is given the option of building the initial global catalog from media. At that time, the CD with the global catalog file can be inserted and the initial catalog information installed. Replication to the network will occur, but only for changes made to the global catalog since the CD was created.

This process is covered in detail in Chapter 3, and is commonly used as a method of creating global catalog servers when a global catalog needs to be created across a WAN.

IPSec NAT Traversal

Windows Server 2003 provides better remote user security with IPSec NAT Traversal (NAT-T). Internet Protocol Security provides an end-to-end encryption of information for server-to-server or for client-to-server secured communications. Unfortunately, with IPSec, the source and destination servers must have public Internet addresses where Network Address Translation (NAT) is not used. For site-to-site communications, an organization typically can create public IP addresses to servers on each end of the site-to-site connection. However, mobile users who may connect at hotels, airports, or other temporary locations are rarely assigned public IP addresses; thus, IPSec has not been very functional for mobile users wanting to securely access their networks running Windows 2000.

Windows Server 2003 provides IPSec NAT Traversal that enables IPSec servers and clients to traverse Network Address Translation network segments. With IPSec NAT Traversal, an organization can increase the remote-to-server security and provide secured mobile communications much better than it has ever been able to do before.

IPSec NAT Traversal is covered in Chapter 26, "Server-to-Client Remote and Mobile Access."


Windows Server 2003 for Better User Services

Most of the improvements in Windows Server 2003 covered so far in this chapter typically occur behind the scenes from the users and are not something that day-to-day users would notice or appreciate. The services described in this section address tools and technologies that users will directly be able to see and notice significant benefits. These services include improved file management using Distributed File System, better file redundancy and fault tolerance with DFS, and print queue redundancy that will minimize printer interruption or print operation downtime.

File Management with Distributed File System

Windows Server 2003 has a much improved Distributed File System than what was available in Windows 2000, and has been further advanced with the Windows 2003 R2 update. In most organizations, files are distributed across multiple servers throughout the enterprise. Users access file shares that are geographically distributed but also can access file shares sitting on several servers in a site within the organization. In many organizations, when file shares were originally created years ago, server performance, server disk capacity, and the workgroup nature of file and print server distribution created environments in which those organizations had a file share for every department and every site. Thus, files are typically distributed throughout an entire organization across multiple servers.

Windows Server 2003 Distributed File System (DFS) and Windows Server 2003 Distributed File System Replication (DFSR) in Windows 2003 R2 enables an organization to combine file shares to fewer servers and create a file directory tree not based on a server-by-server or share-by-share basis, but rather an enterprisewide directory tree. This allows an organization to have a single directory spanning files from multiple servers throughout the enterprise.

Note

DFSR performs a bit-level replication of data between servers, whereas DFS performs replication at the file level. This means that when a file is modified with DFSR, only a few bits of changed data are replicated to other DFS storage locations as opposed to replicating an entire file.

Because the DFSR directory is a logical directory that spans the entire organization with links back to physical data, the actual physical data can be moved without having to make changes to the way the users see the logical DFS directory. This enables an organization to add or delete servers, or move and consolidate information however it works best within the organization.

DFSR is a significant function that benefits user access to information, and Chapter 30 of this book is dedicated to DFSR and the best practices around planning and implementing DFSR in an organization.

Redundancy and Fault Tolerance of Data with DFSR

In addition to having DFSR provide better manageability to data than ever before, DFSR also provides redundancy and fault tolerance on file data. A built-in DFSR technology called DFS replicas enables an organization to create redundancy and business continuity to its DFSR data. DFSR redundancy and fault tolerance are covered in Chapter 30.

Redundancy with Printer Queues

Many organizations take for granted reliable printer operations and management, and because of the reliability of printing in previous versions of the Windows operating system, print queue redundancy might not be high on an organization's priority list. Windows Server 2003 helps an organization plan again for the potential of print queue failure and provides redundancy to printer queues.

This function allows an organization to set up failover and enables print queues to be stored on multiple servers, thus providing failover in the event of a print queue server failure. Print queue fault tolerance is covered in Chapter 3.


Benefits for Thin Client Terminal Services

Windows Server 2003 released a series of significant improvements to the Terminal Services capabilities for thin client access. A client system working from a browser, a Windows terminal, or running the Remote Desktop Client software from a desktop system can access a centralized Terminal server to gain access to network resources. With Windows Server 2003, these same remote users can now do local drive and audio redirection, have local time zone support, choose the speed of connection to optimize the session performance, and take advantage of a service called Session Directory that provides better redundancy and recoverability in the event of a LAN, WAN, or Internet interruption.

Although all these new capabilities are highlighted here, they are covered in detail in Chapter 27, which addresses their planning, design, prototype testing, implementation, and optimization.

Local Drive and Audio Redirection

An update to Terminal Services in Windows Server 2003 is the ability for a remote client to access local hard drives as well as redirect the audio from a centralized Terminal server to a remote system. In the past, these capabilities required a relatively expensive add-in from Citrix Systems. Now that these capabilities are built into the core Windows Server 2003 Terminal Services, an organization can choose whether it wants to or needs to purchase the add-in.

Local Drive Redirection

Local drive redirection allows a remote user to log on to a centralized Terminal server to access network resources; however, if the user wants to retrieve or save files to a remote system, that system shows up as a drive letter on the session. The user can now drag and drop files between a remote system and the centralized server. The remote file access can include local C: hard drives, CD-ROM drives, floppy drives, or any other device that creates a drive letter for remote system access.

Audio Redirection

Audio redirection allows a remote user to log on to a centralized Terminal server and have sound redirected from the centralized system to the speaker of the remote client system. With organizations integrating voicemail and other audio-integrated tools and utilities into their daily business operations, having the ability to redirect audio to the remote system allows an organization to better support business tools using sound as part of the communication infrastructure.

Local Time Zone Support

With Windows Server 2003 Terminal Services, when a remote user logs on to a centralized Terminal server, the user now can work on either the default time zone on the server or choose the local time zone. This capability is important for organizations that have centralized servers used by employees across the country or around the world.

Earlier versions of Windows had support for only one time zone: the time zone of the Terminal server system. This meant that if the Terminal server was in California and a user from Georgia logged on to the Terminal server, all the individual's email messages or time stamps on file access were based on the Pacific time zone. With local time zone support in Windows Server 2003, now the remote user in Georgia can specify in her remote client access software to use the local time zone. Now when emails are sent, or when files are saved, the time stamp on the communications will be based on the Eastern time zone, where the user resides.

Windows Server 2003 supports all time zones and can have users from all time zones accessing the server at the same time.

Specifying Connection Type

Windows Server 2003 has added a new feature that enables remote users to specify the type of remote connection they have. Rather than having just a single server to remote client session configuration, remote users can specify that they are attaching to the Terminal server over a very slow modem connection, from a mid-speed broadband connection, from a very high-speed LAN connection, or from a customized configuration.

When a user specifies a slow modem connection session, the Terminal server system automatically optimizes server-to-client communications by not running functions that take up session performance such as complicated user backgrounds on a screen desktop. It also optimizes mouse and keyboard controls and disables Windows themes and unnecessary screen animation to provide more communication bandwidth to remote application access functions.

When a user specifies a mid-speed broadband or a LAN connection, more of the features are enabled so that backgrounds, themes, animation, and menu variations are transferred just as if the user were sitting at a desktop at the office.

This minor user-defined optimization enables remote users to improve their session connection and thus their user experience based on the speed of their connection.

Session Directory

New to Windows Server 2003 is a technology called Session Directory that allows remote users to reconnect to the exact same session that they were running before a temporary Internet, dial-up, or WAN connection failure caused a disconnection. This automatic reconnection has always worked fine if the organization has only one Terminal server; however, when an organization had multiple Terminal servers, there was no way for the remote client session to know which of the potential 32 servers to reconnect the user to.

Session Directory now runs on a separate system and keeps track of all user-connected sessions. When a user attempts to log on to one of the servers in a Terminal server load-balanced environment, Session Directory checks whether the user had previously connected to a session that might still be active. If it finds an active session, it reconnects the user to that session, thus restoring the user to exactly the place he left off before being terminated.

Session reconnection requires the Terminal server policy to keep sessions active for a period of time after unexpected disconnection. Best practices allow a remote user up to 10 minutes to reconnect to a dropped connection to re-establish his session right where he left off. However, after 10 minutes, a dropped connection is flushed from the Terminal server to free up server memory, processing capacity, and a remote session software license with the assumption that the remote user might not have been disconnected accidentally, but rather that the user just forgot to log out of the system when he was done. Session reconnection provides a variety of features and options that are addressed in detail in Chapter 27.


Benefits for Improved Management

Windows Server 2003 adds a series of tools and new utilities to improve system management. The tools help network administrators recover from system failures, automate server installations, install software updates and patches from a centralized location, and conduct remote system and server management. These tools and utilities are covered in detail in Chapters 3 and 33.

Automatic Server Recovery

Automatic Server Recovery (ASR) is a system recovery utility built into Windows Server 2003 that allows a server administrator to rebuild a failed server without having to reinstall the operating system or even conduct basic server system configuration steps. ASR effectively takes a snapshot of a server, including the operating system, specific system configuration parameters, and even hard drive stripe set information so that if a server fails, as long as the replacement server has the exact same system configuration, ASR can be used to reinstall the system back to the state it was in before the failure.

When restoring data, ASR does a track-by-track restoration of information, so hard drives do not need to be formatted or restriped. Before ASR, at a minimum, an administrator had to install hardware components, restripe hard drives, and load the Windows operating system. With ASR, all an administrator needs to do is plug in hard drives to a server, boot to the Windows Server 2003 installation CD, and choose to do a system recovery. ASR is covered in more detail in Chapter 33.

Remote Installation Service for Servers

New to Windows Server 2003 is a server tool called Remote Installation Services for Servers, or RIS for Servers. RIS for Servers allows an organization to create images of server configurations that can then be pushed up to a RIS server that can later be used to re-image a new system. RIS was standard with Windows 2000, but it supports only the re-imaging of desktop systems.

RIS for Servers can be used a couple of different ways. One way organizations have leveraged RIS for Servers has been to create a brand-new clean server image with all of a company's core utilities installed. Every time the organization needs to install a new server, rather than starting from scratch with an installation CD, the organization can use the template RIS server installation. The image could include Service Packs, patches, updates, or other standard setup utilities.

RIS for Servers can also be used as a functional disaster recovery tool. After a server is configured as an application server with the appropriate program files and parameters configured, such as Exchange, SQL, Terminal Services, or the like, an organization can then run the RIPrep utility to back up the application server image to a RIS server. In the event of a system failure, the organization can recover the server image right from the state of the system before system failure.

Note

Creating RIS images for production servers requires planning and testing before relying on the system function for successful disaster recovery. Certain applications require services to be stopped before RIPrep is run. Chapter 33 addresses steps to conduct system server recovery.

RIS for Servers is a versatile tool that helps organizations quickly build new servers or recover from application server failures. Besides being covered in Chapter 33 on disaster recovery, RIS for Servers is also covered in detail in Chapter 3 on new system installation.

Out-of-Band Management

To facilitate the management of a failed server, Windows Server 2003 includes an Out-of-Band Management function that provides for a modem or null modem cable connection to an RS-232 serial port on a Windows Server 2003 for command-line management of the server. As an example, when previous versions of the Windows operating system failed, commonly known as blue-screened, an administrator needed to actually work from the console of the server. Normal remote administration tools like Terminal Services do not work when a server is in a system fault state.

Out-of-Band Management allows an administrator to log on to the system, conduct an image dump, or reboot a server. The administrator also can boot a server in safe mode and remotely modify system parameters before rebooting the system to full operation mode.


Extending the Directory Beyond Active Directory

With the Windows 2003 R2 update, Microsoft has added three new directory services to help organizations better expand the way the organization shares information and how users access information managed by Active Directory. These three directory services are Active Directory Federation Services (ADFS), Active Directory in Application Mode (ADAM), and Identity Management for Unix (IdMU). All these directory services are included in the Windows 2003 R2 update and can be added to an existing Windows 2003 Active Directory environment. More information about ADFS, ADAM, and IdMU is covered in Chapters 5 and 8.

Active Directory Federation Services (ADFS)

One of the new directory services in Windows 2003 R2 is Active Directory Federation Services (ADFS). ADFS provides a way for an organization to effectively join multiple Active Directories into a common, shared authentication and resource sharing environment. Rather than creating a blind trust between the directories of two or more organizations, an organization can build a federated directory between the two organizations that specifically identifies which users can share which resources in the other environment.

This resource sharing is managed through encrypted security tokens with granular security authentication and rights management, where the administrator of one environment can pick the users and choose which resources in another environment those users may access. As an example, one organization may choose a group of eight users who can access a portal in another organization. Rather than adding the eight users to the other organization or creating a blind trust between the two organizations, a federation between the two directories can be created that identifies the eight users in one forest and the portal in the other forest, and provides access rights for the users to the portal on an isolated basis.

Because the federation is managed, administrators can log and track resource access and information sharing. This can help auditors and security management teams understand who had access to which resources for reporting purposes. ADFS is commonly used when there are two organizations with completely separate directories already in existence, or for an organization that needs to clearly maintain two or more directories for information distribution.

Active Directory in Application Mode (ADAM)

Active Directory in Application Mode (ADAM) enables organizations to set up a separate subforest for application schema information while still accessing the main Active Directory for resource sharing. Unlike ADFS, which assumes an organization wants or needs two or more completely independent directories, ADAM assumes that the organization really needs only one directory to manage and administer, but wants to partition the directory in a manner that clearly denotes a separation of individuals and resources within the organization.

ADAM eliminates the need for organizations to set up completely separate forests for external contractors or vendors, for application development testing, or for adding external contractors and users to the Active Directory, which creates a security concern as non-employees are added into the main organizational directory.

Instead, an organization can set up ADAM where an external user can log on to the network, read and write application directory information in the ADAM directory, and access shared resources with Active Directory users, but can do so from a completely separate directory. Organizations that must demonstrate separation between employees and non-employees for regulatory compliance purposes and for separation of security events and services can show that ADAM is managed and maintained separately from core internal Active Directory employees.

Note

Active Directory in Application Mode was a feature pack add-in to Windows 2003. However, with the release of Windows 2003 R2, the Active Directory in Application Mode tool is now included as part of the Windows 2003 R2 update.

Identity Management for Unix (IdMU)

Identity Management for Unix (IdMU) is a Windows 2003 R2 service that provides integration between Windows Active Directory and Unix-based Network Information System (NIS). Rather than having a user log on to Active Directory and then have separate security rights and access resources on Unix systems managed by NIS, IdMU provides an integration between the two directories. Users in Active Directory can be directly assigned rights and privileges to Unix-based resources, and passwords can be automatically synchronized between Active Directory user and NIS user accounts.

This consolidation of resource security and account management functions enhances an organization's capability to centralize and standardize on access rights, password management, and user privileges.

IdMU is discussed in Chapter 8.


Going Beyond the Basic Features of Windows 2003 with Feature Packs

Microsoft has made a commitment to not ship new features and functions in Service Packs, which have frequently caused applications to stop working after a Service Pack update. Microsoft now provides free downloadable Feature Packs to all licensed Windows 2003 organizations. The Feature Packs can be downloaded at http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx.

The Feature Packs include add-ons that provide better group policy management, directory synchronization between Active Directory forests, new tools for network administration, and applications for document storage and management.

Group Policy Management Console

One Feature Pack that every organization should download and use is the Group Policy Management Console (GPMC) tool. With group policies being one of the most important administration, security, and management functions in Active Directory, the GPMC provides a better administrator interface and better functionality for Windows Server 2003 policy management. GPMC enables administrators to more easily create and manage group policies. Rather than having to go through a series of individual policies, administrators can create definition groups that allow the specification of settings allowing specific actions for users and computers.

Additionally, GPMC provides definition groups for specifying common system updates, specific application installation, user profile management, and desktop lockdown. GPMC is covered in detail in Chapter 21, "Windows Server 2003 Group Policies."

Software Update Service

Another significant Feature Pack update is the Software Update Service (SUS), which helps organizations perform routine patch management on Windows 2000 and 2003 servers, as well as Windows 2000 and XP workstations. With previous versions of the Windows operating system, an administrator had to check the Microsoft Windows downloads Web site, scan for updates, download the updates, and then apply them on each server in the network. Software Update Service enables network administrators to automatically scan and download updates and patches to a centralized server, and then configure a group policy to automatically distribute the update to servers throughout the organization.

Software Update Service minimizes the effort needed from IT administrators to keep their servers updated with necessary updates and patches. Anything that simplifies the update process provides an organization with a better chance of protecting its servers from known bugs or security flaws. The Microsoft Software Update Service is covered in detail in Chapter 22.

Identity Integration Feature Pack

The Identity and Integration Feature Pack (IIFP) provides directory synchronization between two Active Directory forests. For organizations that want to share directory information, such as a company with two forests, each with their own Exchange 2003 Org structure, IIFP synchronizes usernames and distribution list information between the forests so that email can flow back and forth between the organizations. IIFP can work between Active Directory 2000 forests, between Active Directory 2003 forests, and between an Active Directory 2000 and an Active Directory 2003 forest. It will also synchronize between Active Directory and ADAM, allowing the flow of objects and attributes to and from the application directory. IIFP is covered in detail in Chapter 8, "Integrating AD with Novell, Unix, and NT4 Directories."

Directory Services Markup Language Services for Windows

The Directory Services Markup Language (DSML) allows Active Directory access using SOAP integrated into Web services. This provides organizations with the capability to extend access to Active Directory from XML-based Web pages. This has been commonly used for directory lookup or for distributed Web-based administration and management. DSML is covered in Chapter 23.

Remote Control Add-on for Active Directory Users and Computers

For administrators who provide remote control support to servers or desktop systems, rather than launching the Remote Desktop Connection tool to perform remote administration, an administrator already in the Active Directory Users and Computers MMC tool can simply right-click on a computer account and have remote access to the remote system. The Remote Control add-on for Active Directory Users and Computers minimizes the number of separate tools that need to be loaded and used by administrators, and simplifies the task of remembering server and system names when the resources are all listed and organized within the Active Directory Users and Computers MMC tool. The Remote Control Add-on for Active Directory Users and Computers is covered in Chapter 28, "Windows Server 2003 Administration Tools for Desktops."

Services for NetWare 5.03

Microsoft is also including significant tool updates such as Service Packs on the Feature Pack download page. One of the major updates for a Windows Server 2003 tool is version 5.03 for Services for NetWare (SfN). SfN provides integration between Windows 2003 and a Novell NetWare environment. The Service Pack rolls up the latest patches and utility updates into a single update. SfN is covered in Chapter 8.

Windows SharePoint Services

A significant update provided free to all Windows 2003 licensed organizations is the Windows SharePoint Services Feature Pack, which is covered extensively in Chapter 36, "Windows SharePoint Services." Windows SharePoint Services (WSS) is a document-storage management add-on that provides organizations with the capability to better manage, organize, and share documents, as well as provide teams of users the ability to collaborate on information. Many believe that WSS could have been sold as a completely separate product, but Microsoft chose to include it as a free download to Windows 2003, and with Windows Server 2003 R2 the files for SharePoint Services are automatically copied onto the server as part of the R2 update.

Windows SharePoint Services sets the framework from which the SharePoint Portal Server 2003 (SPS) is built. SPS leverages the core functionality of WSS and extends the capability into enterprise environments. WSS is the basis of document-sharing and communications for organizations in the evolution of file and information communications.

Windows Rights Management Services

Windows Rights Management Services (RMS) is available for download on the Feature Pack page and provides organizations the tools to improve the security of files, documents, and communication between users. RMS sets the framework for secured information sharing down to the file and message level, and eliminates the need for different encryption and document-change control tools for email, documents, and other network communication media. Windows Rights Management is covered in Chapter 15, "Security Policies and Security Tools."

Windows System Resource Manager

Windows System Resource Manager (WSRM) was one of the first Feature Packs released by Microsoft, and has been made available for download to help organizations better manage server resources. Rather than letting applications grab as much memory as they want, or allowing applications to trigger high bandwidth demands on servers without administrative control, WSRM gives administrators a tool to throttle system resource demand.

As an example, if an accounting department prints a very large report every quarter, rather than having the report processing take up 90% of the server utilization for 10 minutes while the report takes the next three hours to print, WSRM can be activated to throttle server utilization to possibly 15%, so that the processing of the report and the printing of the report take three hours to complete without creating spiked demands on the server. Other uses of WSRM include the capability to throttle terminal server sessions so that a single terminal server user does not take up all the RAM and CPU available on a servertheir memory and server utilization is controlled. This can permit more users to access the terminal server with only moderate performance impact, rather than one user taking up all the server performance and affecting all the users on the system. WSRM is covered in detail in Chapter 27.


Extending the Capabilities of Windows 2003 with Downloadable Tools

In addition to Feature Packs, Microsoft has made available new and updated tools that help organizations with migration, administration, maintenance, and management tasks. These tools are freely downloadable to all Windows 2003 licensed organizations at http://www.microsoft.com/windowsserver2003/downloads/default.mspx.

Active Directory Migration Tool v2.0

The Active Directory Migration Tool came with Windows 2000 as a version 1.0 release, and has undergone major renovations since then. ADMT v2.0, which is freely downloadable from the Windows Server 2003 Tools site, enables an organization to migrate user accounts, computer accounts, access control lists (ACLs), and trusts from NT4 or Windows 2000 to a Windows Server 2003 domain. Unlike previous versions of ADMT that migrated user objects but did not migrate passwords, ADMT v2.0 can migrate passwords from the source to destination domain.

Additionally, ADMT v2.0 can migrate objects between Active Directory forests, more commonly called the cross-forest migration of objects. This capability now allows an organization to set up a brand-new Active Directory forest and migrate objects to the new forest. This can be done when an organization wants to migrate all objects from an old forest to a new forest, or when an organization has a department, subsidiary, or remote location that accidentally created its own Active Directory forest and now wants to blend it into the main organization's forest. ADMT v2.0 provides a variety of migration options for organizations, and is covered in detail in Chapter 17.

Domain Rename

When migrating from Windows 2000 to Windows Server 2003, many organizations choose to change their domain names in the process. When Windows 2000 first shipped, performing a domain rename was not possible, so this capability has been long awaited by organizations that might have set a domain name that they no longer want (such as a domain named after a television series or for a specific site that does not exist anymore), or whose name changed after a merger or acquisition. Windows Server 2003 enables an organization to rename a domainboth the NetBIOS name, as well as the fully qualified DNS domain name.

Although domain renaming is possible, it is not a simple task because a domain rename affects all domain controllers, servers, and systems attached to the domain. Effectively, every single system on the network will need to be reconfigured and rebooted. Although the domain rename tool helps to automate this process, certain systems might not successfully reconnect to the new domain and administrator intervention is required. If an organization has hundreds or thousands of systems connected to a domain, the need to clearly validate the requirement to change a domain name must be considered. The domain rename utility is covered in detail in Chapter 17.

Application Compatibility Tools

Another pair of Windows 2003 tool downloads are the Application Compatibility Analyzer and the Windows Application Compatibility Toolkit. These tools help organizations test applications to confirm compatibility with Windows Server 2003, and to isolate problems with compatibility to either work around the problem or to decide that the application needs to be replaced. These application compatibility tools are covered in Chapter 18, "Compatibility Testing."

Log Parser Tool

Microsoft provides a pair of log-parsing tools on the Windows 2003 Tools download page. The tools allow an administrator to quickly search for patterns and data in the log files of multiple servers, without having to open and search each server's log files individually. The log-parsing tools also provide extensive reporting tools, as well as the capability to export data from the log files into a SQL database.

Although Microsoft has an extensive log-tracking, management, and reporting tool that it sells as a separate program called Microsoft Operations Manager, the Log Parser tools are free and provide basic functionality for log file administration. The Log Parser tools are covered in Chapter 22.

Microsoft Operations Manager Tools

Although Microsoft Operations Manager (MOM) is a separate Microsoft program that can be purchased to manage and administer Windows servers, the downloadable components on the Windows Server 2003 tools page are the add-on components for MOM for Windows 2003 systems. There are several downloads on the Windows Server 2003 tools page. One download is the Base Management Pack, which has the core monitoring tools for Active Directory, Internet Information Service, Windows networking, and file replication services. Another download is the Microsoft Operations Manager Resource Kit, which has tools that extend the capabilities of MOM including a Server Status Monitor tool (SSM) that enables an organization using MOM to monitor the simple up or down status of a group of servers.

Other MOM tools include the MIIS 2003 Management Pack and the MIIS 2003 Resource Kit, which provide functionality for managing directory replication and integration between Active Directory and other MIIS-managed directories. The Microsoft Operations Manager tools are covered in Chapter 25, "Integrating MOM with Windows Server 2003."

File Replication Management Tools

Another significant series of tools available for download include file replication management tools such as sonar.exe and frsdiag.exe, which are tools that help administrators validate the replication between servers. Something that was found to be significant in the ongoing administration and management of Windows is the ability for administrators to ensure that all the global catalog servers and file replication servers are communicating properly. If a global catalog server is not replicating properly on the network, any users that access the global catalog server might not receive the latest group policies, or have the proper security or administrative policies applied.

By using the file replication management tools from the Windows 2003 Tools page, administrators can validate that replication is occurring as expected, or the administrator can manually force a replication from within the tools. File replication management tools are covered in Chapter 30 as well as in Chapter 21.

Getting to Know Windows 2003 Resource Kit Tools

In addition to Feature Packs and downloadable Windows 2003 Tools that greatly enhance the administration and management of a Windows 2003 network, administrators should understand how the various Windows 2003 Resource Kit tools can provide significant support in daily tasks. Unlike some resource kits from Microsoft that used to require the purchase of the tools, the Windows 2003 Resource Kit tools are freely downloadable from the Windows 2003 Tools page to all licensed Windows 2003 organizations.

This second edition of Windows Server 2003 Unleashed has taken the most significant Windows 2003 Resource Kit tools and noted how the tools are best used in leveraging tasks and functions in a Windows 2003 environment. As an example, one of the tools, like the Remote Access Quarantine client covered in Chapter 26, is a free tool that isolates VPN clients and only allows the remote access users access to the network when their system is cleared for appropriate patch updates and virus scans. For a free downloadable tool, an organization can set up a sophisticated system for scanning and validating that a remote laptop or desktop is clean and can access network resources.

Additional Resource Kit tools include Group Policy monitoring and Group Policy editing tools that provide command-line tools for managing Group Policies. Rather than always launching the GPO Edit MMC utility, many tasks can be done from a command-line, making the scripting and batch processing of policy tasks a simpler process. The Group Policy Resource Kit-related tools are covered in Chapter 21.

Several maintenance tools included in the Windows Server 2003 Resource Kit provide replication checks, link checks, clear the memory on servers, provide SMTP DNS diagnostics, check for memory leaks on servers, look for page faults on servers, and the like, and are covered in Chapter 34, "Logging and Debugging." The tools are typically poorly documented in the Microsoft Resource Kit document; however, the tools are highlighted throughout this book to add better automation to mundane processes, as well as provide the needed administrative support to scripted tasks.


Getting Started with Windows Server 2003

This introductory chapter was intended to highlight the new features, functions, migration tools, and management utilities in Windows Server 2003 that will help administrators take advantage of the capabilities of the new operating system. If Windows Server 2003 is seen as just a simple upgrade to Windows NT4 or Windows 2000, an organization will not benefit from the operating system enhancements. However, when fully leveraged with the capabilities of the Windows Server 2003 operating system, an organization can improve services to its employees through the use of new tools and technologies built into the operating system.


Best Practices

  • To ultimately improve Windows security, tune and optimize Microsoft's Windows Server 2003 for a secured networking environment.

  • Better manage files and printers through the use of new Windows 2003 R2 tools such as File Server Resource Manager (FSRM) and Print Management Console (PMC).

  • Take advantage of the key standards built into Windows Server 2003, including, but not limited to, IPv6, XML Web services, and IETF Security Standards.

  • Consider using the domain rename utility to rename a domain rather than build the domain from scratch.

  • Migrate user accounts, computer accounts, access control lists (ACLs), and trusts from NT4 or Windows 2000 to a Windows Server 2003 domain using the Active Directory Migration Tool (ADMT) version 2.0.

  • Use Terminal Services in Windows Server 2003 to provide users access to local hard drives as well as to redirect the audio from a centralized Terminal server to a remote system.

  • Use Software Update Service (SUS) to automatically scan and download updates and patches to a centralized server for testing prior to distributing to all servers and client machines.

  • The Group Policy Management Console Feature Pack is a must for all administrators to install and use for their administration of Group Policies in a Windows 2003 environment.

  • Get better directory interoperability with Active Directory Federation Services (ADFS), Active Directory in Application Mode (ADAM), and Identity Management for Unix (IdMU).

  • An administrator should get familiar with all of the Feature Packs and Windows 2003 tools available for download. These tools in many cases update the tools that were included with the original version of Windows 2003, or are completely new tools that provide needed functionality to the tasks of upgrading, updating, administering, and managing a Windows 2003 environment.

  • The Windows 2003 Resource Kit now provides free tools to Windows 2003 administrators that can drastically improve mundane administrative tasks by simplifying management tasks into scripts, command-line queries, or quick lookup views.

  • Combine group policy with SUS to automatically distribute and manage regularly updating servers with Service Packs, patches, and security updates.


Chapter 2. Planning, Prototyping, Migrating, and Deploying Windows Server 2003 Best Practices

In This Chapter

  • Determining the Scope of Your Project

  • Identifying the Business Goals and Objectives to Implement Windows Server 2003

  • Identifying the Technical Goals and Objectives to Implement Windows Server 2003

  • The Discovery Phase: Understanding the Existing Environment

  • The Design Phase: Documenting the Vision and the Plan

  • The Migration Planning Phase: Documenting the Process for Migration

  • The Prototype Phase: Creating and Testing the Plan

  • The Pilot Phase: Validating the Plan to a Limited Number of Users

  • The Migration/Implementation Phase: Conducting the Migration or Installation

Far too many organizations implement a new application or upgrade to the new version of an operating system without fully understanding the goals and objectives of the upgrade and the breadth and scope of benefits the implementation will provide. While the migration is completed successfully from a technical implementation perspective, far too frequently users don't acknowledge significant improvements from the implementation, and the business goals and objectives of the organization's executives are not realized. This lack of vision of the implementation's benefits can jeopardize funding of future projects and affect the satisfaction of the user community.

This chapter examines how a structured four-step process for migrating to the Windows Server 2003 environment can enhance the success of the project. Consisting of discovery, design, testing, and implementation phases, this methodology can be scaled to meet the needs of the wide variety of organizations and businesses that use Microsoft technologies. The results of this methodology are three very important documents created to map out the implementation process: the design document, the migration document, and the migration plan.

The examples used in this chapter assume that the environments being migrated are primarily NT4 or Windows 2000 based, but the concepts and process can certainly apply to other environments.


Determining the Scope of Your Project

As outlined in the preceding chapter, the Windows Server 2003 platform contains such a wealth of features that planning a migration to it can seem quite daunting at first. This chapter provides some guidance and best practices that can assist with the process and assist organizations in creating a well-thought-out and structured implementation plan.

Rather than forging ahead with no plan or goals and simply building new servers, loading application software, and inserting them into an existing network environment, a more organized process will control the risks involved and define in detail what the end state will look like.

The first steps involve getting a better sense of the scope of the project, in essence writing the executive summary of your design document. The scope should define from a high level what the project consists of and why the organization is devoting time, energy, and resources to its completion.

Creating this scope of work requires an understanding of the different goals of the organization, as well as the pieces of the puzzle that need to fit together to meet the company's stated goals for the project. For Windows Server 2003, the primary pieces are servers that handle key network functionality, servers that handle and manage the data, servers that control or provide access to the information, and servers that handle specific applications.


Identifying the Business Goals and Objectives to Implement Windows Server 2003

It is important to establish a thorough understanding of the goals and objectives of a company that guide and direct the efforts of the different components of the organization, to help ensure the success of the Windows Server 2003 project. It may seem counterintuitive to start at this very high level and keep away from the bits- and bytes-level details, but time spent in this area will clarify the purposes of the project and start to generate productive discussions.

As an example of the value of setting high-level business goals and objectives, an organization can identify the desire for zero downtime on file access; this downtime could be facilitated through the implementation of the Distributed File System (DFS) technology or the Windows Server 2003 Volume Shadow Copy technology. So starting with the broad goals and objectives will create an outline for a technical solution that will meet all the criteria the organization wants, at a lower cost, and with an easier managed solution.

In every organization a variety of different goals and objectives need to be identified and met for a project to be considered successful. These goals and objectives represent a snapshot of the end state that the company or organization is seeking to create. For a smaller company, this process might be completed in a few brainstorming sessions, whereas larger companies may require more extensive discussions and assistance from external resources or firms.

High-Level Business Goals

To start the organizational process, it is helpful to break up business goals and objectives into different levels, or vantage points. Most organizations have high-level business goals, often referred to as the "vision of the company," which are typically shaped by the key decision makers in the organization (such as the CEO, CFO, CIO, and so on); these goals are commonly called the "50,000-foot view." Business unit or departmental goals, or the "10,000-foot view," are typically shaped by the key executives and managers in the organization (such as the VP of Sales, HR Director, Site Facilities Manager, and so on). Most organizations also have well-defined "1,000-foot view" goals that are typically very tactical in nature, implemented by IT staff and technical specialists.

It is well worth the time to perform some research and ask the right questions to help ensure that the networking system implementation will be successful. To get specific information and clarification of the objectives of the different business units, make sure the goals of a technology implementation or upgrade are in line with these business goals.

Although most organizations have stated company visions and goals, and a quick visit to the company's Web site or intranet can provide this information, it is worth taking the time to gather more information on what the key stakeholders feel to be their primary objectives. Often this task starts with asking the right questions of the right people and then opening discussion groups on the topic. Of course, it also matters who asks the questions, because the answers may vary accordingly, and employees may be more forthcoming when speaking with external consultants as opposed to co-workers. Often the publicly stated vision and goals are "the tip of the iceberg" and may even be in contrast to internal company goals, ambitions, or initiatives.

High-level business goals and visions can vary greatly between different organizations, but generally they bracket and guide the goals of the units that make up the company. For example, a corporation might be interested in offering the "best" product in its class, and this requires corresponding goals for the sales, engineering, marketing, finance, and manufacturing departments. Additional concepts to look for are whether the highest-level goals embrace change and new ideas and processes, or want to refine the existing practices and methods.

High-level business goals of a company can also change rapidly, whether in response to changing economic conditions or as affected by a new key stakeholder or leader in the company. So, it is also important to get a sense of the timeline involved for meeting these high-level goals.

Note

An example of some high-level business goals include a desire to have no downtime, access to the network from any of the organization's offices around the world, and secured communications when users access the network from home or a remote location.

Business Unit or Departmental Goals

When the "vision" or "50,000-foot view" is defined, additional discussions should reveal the goals of the different departments and the executives who run them. Theoretically, they should "add up" to the highest-level goals, but the findings may be surprising. Whatever the case turns out to be, the results will start to reveal the complexity of the organization and the primary concerns of the different stakeholders.

The high-level goals of the organization also start to paint the picture of which departments carry the most weight in the organization, and will most likely get budgets approved, and which will assist in the design process. Logically, the goals of the IT department will play a very important role in a network operating system (NOS) migration project, but the other key departments shouldn't be forgotten.

As an example of the business unit or departmental goals for an organization, an HR department may typically influence the decision for right-to-privacy access to core personnel records. Or a legal department may typically influence security access on information storage rights and storage retention.

If the department's goals are not aligned with the overall vision of the company, or don't take into account the needs of the key stakeholders, the result of the project may not be appreciated. "Technology for technology's sake" does not always fulfill the needs of the organization and in the long run is viewed as a wasteful expenditure of organizational funds.

In the process of clarifying these goals, the features of the network operating system and network applications that are most important to the different departments and executives should become apparent. It is safe to assume that access to company data in the form of documents or database information, and to communications tools such as email, faxing, and Internet access, and to the vertical market software applications that the company relies upon will affect the company's ability to meet its various business goals.

The Sales department will most likely have goals that require a specific client relationship management (CRM) application as well as access to key company data and communications tools. Likewise, the Finance department will have applications that track specific AR and AP information and that most likely tie into applications used by other departments. The IT department will have its key technologies that support the applications in use, store and maintain the company's data, and manage key servers and network devices.

It is also worth looking for the "holes" in the goals and objectives presented. Some of the less glamorous objectives, such as a stable network, data recovery abilities, or protection from the hostile outside world, are often neglected.

A by-product of these discussions will ideally be a sense of excitement over the possibilities presented by the new technologies that will be introduced, and will convey to the executives and key stakeholders that they are involved in helping to define and craft a solution that takes into account the varied needs of the company. Many executives look for this high-level strategy, thinking, and discussions to reveal the maturity of the planning and implementation process in action.

Note

An example of some departmental goals include a desire to have secured storage of human resource and personnel information, 30-minute response time to help desk questions during business hours, 24-hour support for sales executives when they are traveling, and easy lookup to files stored on servers throughout the organization.


Identifying the Technical Goals and Objectives to Implement Windows Server 2003

Although an operating system upgrade Windows Server 2003 may not initially seem integral to the highest-level company goals, its importance will become clearer as the goals get close to the "1,000-foot view." When the business goals are sketched out, the technical goals should fall into place quite naturally.

At this point in the process, questions should focus on which components and capabilities of the network are most important, and how they contribute to or hinder the goals expressed by the different units.

As with business goals, the technical goals of the project should be clarified on different levels (50,000-foot, 10,000-foot, 1,000-foot, and so on). At the highest level, the technical goals might be quite vague, such as "no downtime" or "access to data from anywhere." But as the goals are clarified on a departmental and individual level, they should become specific and measurable. For example, rather than identifying a goal as "no downtime," ferreting out the details might result in a more specific goal of "99.99% uptime during business hours, and no more than four-hour downtime during nonbusiness hours scheduled at least two days in advance." Instead of stating a goal of "access to data from anywhere," a more specific goal of "high-speed remote logon from any corporate regional office around the world and dial-up or VPN access from the home offices of the organization's senior managers" can more reasonably be attained.

Part of the art of defining technical goals and objectives also resides in limiting them. Data can be accessed in many different ways, and the complexity of the network environment can boggle even the veteran IT manager's mind. So, for example, rather than setting a goal of "remote access to all employees," a more focused goal such as "access to email for all employees, remote access to email and the accounting software for the Finance department, and remote access to email and the client relationship management software for sales executives" is more actionable.

Departmental technical goals can include "1,000-foot" itemsfor example, implementing a new software application or set of functions that require other network changes, such as an operating system upgrade Windows Server 2003. The Marketing department may require some of the advanced features of the latest version of Exchange, as well as enhanced Web site capabilities that necessitate the implementation of Windows Server 2003 and the .NET family. Or the Sales department may require better remote access to the company's data through mobile devices and the Internet, and a solution was already chosen that involves the Windows .NET platform.

Two key components should also be included in these discussions: budget and timeline. A huge amount of time in the design phase can be saved if these components are clarified (and agreed upon) early in the process. Some projects have to happen "yesterday," whereas others can happen over a period of quarters or even years. In most cases, the budget will vary with the time frame involved, because longer timelines enable organizations to train resources internally and migrate in a more gradual fashion. Even if a firm budget or timeline isn't available, order of magnitude ranges can be established. If $500,000 is too much, how about $250,000? $100,000 to $250,000? If a year is too long, but budget won't be available for four months, the time frame becomes better clarified.

Defining the Scope of the Work

By now, the list of goals and objectives may be getting quite long. But when the myriad of business and technical objectives as well as the overall priorities start to become clear, the scope of work starts to take shape. A key question to ask at this point, to home in on the scope of the project, is whether the migration is primarily an operating system upgrade or an application upgrade. Often the answer to this question seems clear at first but becomes more complex as the different goals of the business units are discussed, so the scope of work that is created may be quite different than it appeared at first.

Specifically, a decision needs to be made whether the entire network operating system (NOS) needs to be upgraded or only a subset of it, and what other infrastructure components need to be changed or replaced. This section focuses on the server components, but later chapters will focus on other hardware and software areas that should be reviewed.

Upgrading to the latest version of a key network application (CRM solution, document management system, or remote access solution) may require a network operating system upgrade, but it may need to involve only a limited portion of the network (perhaps only one server). Yet if this application needs to be accessed by every member of the organization, in several offices, and requires upgrades to data storage solutions, tape backup software, antivirus software, remote access, and connectivity between offices, a full NOS upgrade may make more sense. An upgrade Windows Server 2003 enterprisewide can allow centralization of resources, consolidation of servers, enhanced management tools, and other features that may make a larger project more attractive.

It is important to also examine how the business and technology goals fit into this plan. If one of the goals of the organization is 99.99% uptime during business hours, this may well affect the migration process and limit changes to the network to weekends or after hours. Or a goal that involves a dramatically short timeline may likewise affect the strategy and require a partial NOS upgrade.

Questions raised at this point may require further discussion and even research. The section, "The Discovery Phase: Understanding the Existing Environment" later in this chapter examines some areas that generally need review. But with a solid understanding of the different departmental and companywide goals for the project, you can sketch out a basic outline of the required configuration.

You need to get answers to these sample questions:

  • How many servers need to be upgraded?

  • Where do these servers reside?

  • What core business applications need to be upgraded?

  • What additional applications and devices need to be upgraded or modified to support the new servers and applications?

  • How will this affect the desktop configurations?

Based on the goals and objectives for the project and the answers to these types of questions, the high-level scope of the work begins to take shape. Here are some general rules to consider:

  • Keep it as simple as possible.

  • Break up the project into logical segments.

  • Don't forget that the staff and user community will need to learn new skills to be productive.

Often it makes sense to upgrade the operating system first; then add directory services and file and print functionality; and finally ensure the system is properly protected with a compatible backup solution, virus protection, and disaster recovery plan. When this foundation is in place, the applications can be migrated in a more gradual process. In other cases, the new application must be installed in advance of the operating system upgrade, for testing purposes, or because of budget limitations or a tight timeline.

Implementing the latest version of Exchange is a good example; this implementation requires not only a core operating system upgrade (to Windows 2000 or Windows Server 2003) but also requires that the Windows Active Directory is properly implemented. On the other hand, for an organization implementing SharePoint Team Services (STS), because STS does not require Active Directory to make the application fully functional, the organization can choose to implement just Windows Server 2003 as an application server and can delay the implementation of Active Directory or other Windows Server 2003 services to a future date.

Note, however, that if the NOS in use is too old or no longer supported by the manufacturer, the upgrade choices might be limited. You may simply have to implement a completely new collection of servers with compatible network applications and phase out the old ones.

Often an application-focused upgrade will introduce a limited number of new servers but also set the stage for the eventual migration. But this can be an effective way to implement the new technology in a faster method than an enterprisewide operating system upgrade. A partial upgrade also may defer the costs of purchasing new server licenses, client access licenses, and other enterprisewide applications, including virus protection and tape backup. Ideally, the servers that are upgraded for the new application(s) should be designed to integrate into the NOS after a full-fledged upgrade. In other words, ideally these servers won't need to be rebuilt later.

As will be discussed in Chapter 8, "Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories," Windows Server 2003 is designed for compatibility and co-existence with a variety of other network operating systems in addition to NT Server and Windows 2000 servers. An important point to consider during the design process is whether it makes sense to upgrade the entire NOS even though doing so may not be absolutely essential. There may be convincing arguments for a complete upgrade because management of a uniform environment can be easier to administer organization-wide, and an upgrade Windows Server 2003 may solve a number of existing issues.

Again, the answers may not be obvious at this point in the design process. But by asking the questions and engaging in "what if" discussions and speculations, the primary pieces of the puzzle can be identified. The next step is to determine how best to fit those pieces together.

Determining the Time Frame for Implementation or Migration

An equally important component of the migration is the time frame, and this component will affect the path and process that needs to be followed to create the results desired. Often the goals for the project will dictate the timeline, and the technology upgrade can drastically affect other critical business project dependencies. Other upgrades may not have strict timelines, and it is more important that the process be a smooth one than a quick one.

Dependent on the scope of the project, a time frame of two to four months could be considered to be a short time frame, with four to six months offering a more comfortable window. Within these time constraints, several weeks are available for discovery and design, a similar amount of time is available for the testing process, and then the implementation can proceed.

A fundamental point to remember is that change will bring with it a learning curve to both the user communities and the administrative staff. And the greater the amount of change that employees need to adjust to, the more support and training will be required to ensure their productivity when the new platform is rolled out. This is especially true when the applications change along with the operating system.

A safe strategy to take when sketching out the timeline is to start by setting a completion date and then working backward from it, to get a sense for the time available to each component of the process. As this chapter discusses, the project has several key phasesdiscovery, design, prototype, and implementationand sufficient time should be allowed for each one of them. Although there are no hard and fast rules of how the time should be split up between each of these phases, each phase tends to take longer than its predecessor, and the discovery and design phases typically take as long, combined, as the testing phase (that is, discovery + design = prototype time frame).

The implementation phase will vary tremendously based on the scope of the project. For simpler projects, where the implementation consists only of a new server housing a new application, the implementation may be as simple as "flipping a switch" over a weekend (assuming the solution has been thoroughly tested in the lab environment). At the other end of the spectrum, a full NOS upgrade, happening in several locations, with changes required on the desktop, can take a period of months or quarters.

Even when the deadline for the completion of the project is the infamous "by yesterday," time should be allocated for the design and planning process. If time and energy are not invested at this point, the prototype testing process may be missing the mark because it may not be clear exactly what is being tested, and the implementation may not be smooth or even successful. A good analogy here is that of the explorer who sets off on an adventure without planning what should go in her backpack or bringing a map along.

Slower, phased migrations typically occur when the existing environment is fairly mature and stable, and the vertical applications are still fairly current and meet the company's needs.

Slower time frames should allow a period of weeks or months for the staff to fully understand the goals of the project and requirements of the key stakeholders, review the existing environment, and document the design. Time will also be available to choose the right partner for the project, train the internal resources who will assist in (or lead) the process, and prototype the solution in a safe lab environment. Assuming the testing is successful, a phased implementation can further limit the risks of the project, and the pilot phase of the implementation will allow the staff to learn lessons that will smooth out the remaining phases.

Milestones should be set for the completion of the phases, even if they aren't essential to the project's success, to keep momentum going and to avoid the "never-ending project." Projects without periodic dates set as interim milestone points will almost certainly not meet an expected completion date. Projects that extend too far beyond the allotted time frame add costs and risks such as employee turnover, changing business conditions, and new revisions of hardware and software products.

Naturally, projects with shorter timelines bring their own challenges, and typically some compromises need to be made to successfully complete a large project in a limited amount of time. However, it is important not to abandon the basic principles of discovery, design, and testing. If these steps are skipped and an upgrade is kicked off without planning or a clear understanding of the desired results, the result will more often than not be flawed. In fact, the result may never even be reached because "show stoppers" can suddenly appear in the middle of the project.

It is usually possible to meet a quick timeline (a number of weeks at the very least) and have the results make the stakeholders happy. The real key is to understand the risks involved in the tight time frame and define the scope of the project so that the risks are controlled. This might include putting off some of the functionality that is not essential, or contracting outside assistance to speed up the process and leverage the experience of a firm that has performed similar upgrades many times.

Hardware and software procurement can also pose delays, so for shorter time frames, they should be procured as soon as possible after the ideal configuration has been defined. Note that often the "latest and greatest" hardwarethat is, the fastest processors and largest-capacity drivesmay take longer to arrive than those a step down. The new equipment should still be tested or "burned in," in a lab environment, and fine-tuned, but can often be moved right into production with the pilot implementation. For most medium and large organizations, it is recommended that a permanent lab be set up; this step will be discussed in more depth in the section, "The Prototype Phase: Creating and Testing the Plan" later in this chapter.

Defining the Participants of the Design and Deployment Teams

Division of labor is a key component of the implementation process. Organizations should evaluate the capabilities of their internal staff and consider hiring an outside firm for assistance in the appropriate areas. If the organization understands and defines the roles that internal staff can play, as well as defines the areas where professional assistance is needed, the project will flow more smoothly.

The experience levels of the existing resources should be assessed, as well as the bandwidth that they have available for learning new technologies or participating in a new project. If the staff is fully occupied on a daily basis supporting the user base, it is unlikely that they will be able to "make more time" to design and plan the new implementation, even with outside assistance. The track record of the existing staff often reveals how the next project will turn out, and if there are existing half-finished or unsuccessful projects, they can interfere with a new project.

While classroom-style training and manufacturer-sponsored training do not guarantee expertise, they do indicate the IT staff's willingness to learn and illustrate that they are willing to dedicate time to learning new technologies. A new implementation can be a great opportunity to test the commitment levels of the existing staff and also to encourage them to update their skills.

Consider also how the changes to the environment will affect the complexity of the environment that will need to be supported. For example, an upgrade Windows Server 2003 may enable a company to consolidate and reduce the number of servers on the network and replace "flaky" applications with more stable ones. An upgrade may also introduce brand-new tools that may add support duties in unfamiliar areas to the existing staff.

After the organization takes an inventory of resources at this level and determines roughly what percentage of the project can be handled internally, an external partner should be considered. Even a smaller organization faced with a relatively simple project of, say, installing a Windows Server 2003 handling one new application can benefit from outside assistance. Some tight time frames necessitate delegating 90% of the tasks to outside resources, while other, more leisurely projects, may require only 10% assistance levels.

A key distinction to make at this point is between the design resources and the deployment resources. The company or individuals in charge of the design work must have significant experience with the technologies to be implemented and be able to educate and lead the other members of the project team. For projects of moderate or greater complexity, these resources should be dedicated to the design process to ensure that the details are fully sketched out, and the solution designed is as well thought out as possible. Often the design team has the challenging task of negotiating with the key stakeholders concerning the final design, because not all the staff will get everything they want and wish for in the project. The deployment team may contain members of the design team, and these individuals should have training and hands-on experience with the technologies involved and will have more end user interaction.

There are certain prerequisites to look for when choosing an independent consultant or solution provider organization as a partner. Without going into too much detail, the individual or firm should have proven experience with the exact technologies to be implemented, have a flexible approach to implementing the solution, and have specialized resources to handle the different components of the project. No one person can "do it all," especially if he gets sick or goes on vacation, so breadth and depth of experience should be considered. Obviously, the hourly fees charged are important, but the overall costs, if a firm is willing to commit to a cap or not to exceed price, can be more important. In the current business environment, it makes sense to invest your time wisely in choosing a firm that is very good at what it does, or it might not be around in future months when your project reaches its critical phases.

Soft skills of the partner are also important because many projects are judged not only by whether the project is complete on time, on scope, and on budget, but also by the response of the stakeholders and user community. Communications skills, reliability, and willingness to educate and share knowledge along the way bring great value in the long run.


The Discovery Phase: Understanding the Existing Environment

Assuming that the previous steps have been taken, the high-level picture of the Windows Server 2003 upgrade should be very clear by now. It should be clear what the business and technology goals are from a "50,000-foot view" business standpoint all the way down to the "1,000-foot" departmental level. The components of the upgrade, or the scope of the work, and priorities of these components should also be identified as well as the time constraints and who will be on the design and implementation teams.

The picture of the end state (or scope of work) and goals of the project are now becoming clear. Before the final design is agreed upon and documented, however, it is essential to review and evaluate the existing environment to make sure the network foundation in place will support the new Windows Server 2003 environment.

It is an important time to make sure the existing environment is configured the way you think it is and to identify existing areas of exposure or weakness in the network. The level of effort required will vary greatly here, depending on the complexity and sheer scope of the network. Organizations with fewer than 200 users and a single or small number of locations that use off-the-shelf software applications and standard hardware products (Hewlett-Packard, IBM, Cisco) will typically have relatively simple configurations. In contrast, larger companies, with multiple locations and vertical market, custom software and hardware will be more complex. Companies that have grown through the acquisition of other organizations may also have mystery devices on the network that play unknown roles.

Another important variable to define is the somewhat intangible element of network stability and performance. What is considered acceptable performance for one company may be unacceptable for another, depending on the importance of the infrastructure and type of business. Some organizations lose thousands of dollars of revenue per minute of downtime, whereas others can go back to paper for a day or more without noticeable impact.

The discovery work needs to involve the design team as well as internal resources. External partners can often produce more thorough results because they have extensive experience with network reviews and analysis and predicting the problems that can emerge mid-way through a project and become show-stoppers. The discovery process will typically start with onsite interviews with the IT resources responsible for the different areas of the network and proceed with hands-on review of the network configuration.

Developing standard questionnaires can be helpful in collecting data on the various network device configurations, as well as recording input on areas of concern of the network. Key end users may reveal needs that their managers or directors aren't aware of, especially in organizations with less effective IT management or unstable infrastructures. Special attention should be paid to ferreting out the problem areas and technologies that never worked right or have proven to be unstable.

For the most part, the bigger the project, the more thorough the discovery should be. For projects involving a complete NOS upgrade, every affected device and application will need to be reviewed and evaluated to help determine its role in the new environment.

If network diagrams exist, they should be reviewed to make sure they are up to date and contain enough information (such as server names, roles, applications managed, switches, routers, firewalls, and the like) to fully define the location and function of each infrastructure device.

If additional documentation exists on the detailed configuration of key infrastructure devices, such as "As Built" server documents with details on the server hardware and software configurations, or details on router configurations or firewalls, they should be dusted off and reviewed. Information such as whether patches and fixes have been applied to servers and software applications becomes important in the design process. In some cases, the desktop configurations need to be inventoried if client changes are required. Software inventory tools can save many hours of work in these cases.

Certain documented company policies and procedures that are in place need to be reviewed. Some, such as disaster recovery plans or service-level agreements (SLAs), can be vital to the IT department's ability to meet the needs of the user community.

The discovery process can also shed light on constraints to the implementation process that weren't considered previously, such as time restrictions that would affect the window of opportunity for change. These restrictions can include seasonal businesses as well as company budgeting cycles or even vacation schedules.

Ultimately, while the amount of time spent in the discovery process will vary greatly, the goals are the same: to really understand the technology infrastructure in place and the risks involved in the project, and to limit the surprises that may occur during the testing and implementation phases.

Understanding the Geographical Depth and Breadth

At the same time that data is being gathered and verified pertaining to what is in place and what it does, connectivity between devices should also be reviewed, to review the logical components of the network as well as the physical. This information may be available from existing diagrams and documentation, or may need to be gathered in the field.

Important items to understand include: How are DNS, WINS, and DHCP being handled? Are there VPNs or VLANs in place? How are the routers configured? What protocols are in use? What types of circuits connect the offices: T1, fractional T1s, T3, ATM? What are the guaranteed throughputs or CIRs in place?

Has connectivity failure been planned for through a partially or fully meshed environment? Connections to the outside world and other organizations need to be reviewed and fully understood at the same level, especially with an eye toward the security features in place. The best security design in the world can be defeated by a modem plugged in a plain old telephone line and a disgruntled ex-employee.

Along the same lines, remote access needs, such as access to email, network file and print resources, and the support needs for PDAs and other portable devices, should be reviewed.

Geographically diverse companies bring added challenges to the table. As much as possible, the same level of information should be gathered on all the sites that will be involved in and affected by the migration. Is the IT environment centralized, where one location manages the whole environment, or decentralized, where each office is its own "fiefdom"?

The distribution of personnel should be reviewed and clarified. How many support personnel are in each location, what key hardware and software are they tasked with supporting, and how many end users? Often different offices have specific functions that require a different combination of support personnel. Some smaller remote offices may have no dedicated staff at all, and this may make it difficult to gather updated information. Accordingly, is there expansion or contraction likely in the near future or office consolidations that will change the user distribution?

Problems and challenges that the WAN design has presented in the past should be reviewed. How is directory information replicated between sites, and what domain design is in place? If the company already has Active Directory in place, is a single domain with a simple organizational unit (OU) structure in place, or are there multiple domains with a complex OU structure? Global catalog placement should also be clarified.

How is the Internet accessed? Does each office have its own Internet connection, firewall, router, and so on, or is access through one location?

The answers to these questions will directly shape the design of the solution, as well as affect the testing and rollout processes.

Managing Information Overload

Another area that can dramatically affect the design of the Windows Server 2003 solution to be implemented is the place where the company's data lives and how it is managed.

At this point, you should know what the key network software applications are, so it is worth having some numbers on the amount of data being managed and where it lives on the network (one server? ten servers?). The total number of individual user files should be reviewed, and if available, statistics on the growth of this data should be reviewed.

Database information is often critical to an organization, whether it pertains to the services and products the company offers to the outside world, or enables the employees to perform their jobs. Databases also require regular maintenance to avoid corruption and optimize performance, so it is useful to know whether maintenance is happening on a regular basis.

Mail databases pose their own challenges. Older mail systems typically were quite limited in the size of their databases, and many organizations were forced to come up with interesting ways of handling large amounts of data. As email has grown in importance and become a primary tool for many companies, the in-box and personal folders have become the primary storage place for many email users. If the organization uses Microsoft Exchange for its email system, users may have personal stores and/or offline stores that may need to be taken into account.

How the data is backed up and stored should also be reviewed. Some organizations have extremely complex enterprise storage systems and use clustering, storage area networks, and/or a distributed file system to ensure that data is always available to the user community. Sometimes hierarchical storage processes are in place to move old data to optical media or even to tape.

An overall goal of this sleuthing is to determine where the data is, what file stores and databases are out there, how the data is maintained, and whether it is safe. It may also become clear that the data can be consolidated, or needs to be better protected through clustering or RAID solutions. The costs to the company of data loss or temporary unavailability should also be discussed.


The Design Phase: Documenting the Vision and the Plan

With the completion of the discovery process and documentation of the results, it should now be very clear what you have to work with in terms of the foundation the new solution will be implemented upon. Essentially, the research is all done, and many decisions will now need to be made and documented.

By now, a dozen documents could be written; however, the most important document that needs to be created is the design document. This document is a log of the salient points of the discussions that have taken place to date; it should make very clear why the project is being invested in, describe what the scope of the project is, and provide details of what the results will look like. A second document that needs to be created is the migration document, which provides the roadmap showing how this end state will be reached.

Often companies strive for an all-in-one document, but as explained in the next section, there are specific advantages to breaking up this information into two key components. A simple analogy is that you want to agree on what the floor plan for a house will look like (the design) and what the function of each room will be before deciding on how to build it (the migration/implementation).

Collaboration Sessions: Making the Design Decisions

The design team is most likely not ready to make all the decisions yet, even though quite a bit of homework has already been done. A more formal collaborative and educational process should follow to ensure that the end state of the project is defined in detail and that the design team members fully understand the new technologies to be introduced.

The collaborative process involves interactive brainstorming and knowledge-sharing sessions, in which the stakeholders work with facilitators who have expertise with the technologies in question.

Ideally, a consultant with hands-on experience designing and implementing Windows Server 2003 will provide leadership through this process. Well-thought-out agendas can lead the design team through a logical process that educates them about the key decisions to be made and helps with the decisions.

Whiteboards can be used to illustrate the new physical layout of the Windows Server 2003 environment, as well as to explain how the data will be managed and protected on the network. Notes should be taken on the decisions that are made in these sessions. If the sessions are effectively planned and executed, a relatively small number of collaboration sessions will provide the key decisions required for the implementation.

With effective leadership, these sessions can also help establish positive team dynamics and excitement for the project itself. Employees may feel negative about a major upgrade for a wide variety of reasons, but through contributing to the design, learning about the technologies to be implemented, and better understanding their own roles in the process, attitudes can change.

Through these sessions, the details of the end state should become crystal clear. Specifics can be discussed, such as how many servers are needed in which locations, which specific functions they will perform (file and print or application servers, firewalls, and so on), and which key software applications will be managed. Other design decisions and logistical concerns will come up and should be discussed, such as whether to use existing server and network infrastructure hardware or to buy new equipment. Decisions also need to be made concerning secondary applications to support the upgraded environment, such as tape backup software, antivirus solutions, firewall protection, and network management software.

Ideally, some of the details of the actual migration process will start to become clear. For instance, the members of the testing and deployment teams, the training they will require, and the level of involvement from outside resources can be discussed.

Organizing Information for a Structured Design Document

The complexity of the project will affect the size of the document and the effort required to create it. As mentioned previously, this document summarizes the goals and objectives that were gathered in the initial discovery phase and describes how the project's result will meet them. It should represent a detailed picture of the end state when the new technologies and devices have been implemented. The amount of detail can vary, but it should include key design decisions made in the discovery process and collaboration sessions.

The following is a sample table of contents and brief description of the design document:

  • Executive Summary Provides a brief discussion of the scope of the Windows Server 2003 implementation (what are the pieces of the puzzle).

  • Goals and Objectives Includes the "50,000-foot view" business objectives, down to the "1,000-foot view" departmental and stakeholder objectives that will be met by the project.

  • Background Provides a high-level summary of the current state of the network, focusing on problem areas, as clarified in the discovery process, as well as summary decisions made in the collaboration sessions.

  • Approach Outlines the high-level phases and tasks required to implement the solution (the details of each task will be determined in the migration document).

  • End State Defines the details of the new technology configurations. For example, this section describes the number, placement, and functions of Windows Server 2003.

  • Budget Estimate Provides an estimate of basic costs involved in the project. While a detailed cost estimate requires the creation of the migration document, experienced estimators can provide order of magnitude numbers at this point. Also, it should be clear what software and hardware are needed, so budgetary numbers can be provided.

The Executive Summary

The executive summary should set the stage and prepare the audience for what the document will contain, and it should be concise. It should outline, at the highest level, what the scope of the work is. Ideally, the executive summary also positions the document in the decision-making process and clarifies that approvals of the design are required to move forward.

The Goals and Objectives

The goals and objectives section should cover the high-level goals of the project and include the pertinent departmental goals. It's easy to go too far in the goals and objectives sections and get down to the "1,000-foot view" level, but this can end up becoming very confusing, so this information might better be recorded in the migration document and the detailed project plan for the project.

The Background

The background section should summarize the results of the discovery process and the collaboration sessions, and can list specific design decisions that were made during the collaboration sessions. Additionally, decisions made about what technologies or features not to include can be summarized here. This information should stay at a relatively high level as well, and more details can be provided in the end state section of the design document. This information is extremely useful to have as a reference to come back to later in the project when the infamous question "Who made that decision?" comes up.

The Approach

The approach section should document the implementation strategy agreed upon to this point, and will also serve to record decisions made in the discovery and design process about the timeline (end to end, and for each phase) and the team members participating in the different phases. This section should avoid going into too much detail, because in many cases the end design may not yet be approved and may change after review. Also, the migration document should provide the details of the process that will be followed.

The End State

In the end state section, the specifics of the Windows Server 2003 implementation should be spelled out in detail and the high-level decisions that were summarized in the background section should be fleshed out here. Essentially, the software to be installed on each server and the roles that Windows Server 2003 will play (global controllers, domain controllers, DNS services) are spelled out here, along with the future roles of existing legacy servers. Information on the organizational unit (OU) structure, group structures, and replication sites should be included. Diagrams and tables can help explain the new concepts, and actually show what the solution will look like and where the key network devices will be located and how the overall topology of the network will change. Often, besides a standard physical diagram of "what goes where," a logical diagram illustrating how devices communicate is needed.

The Budget Estimate

The budget section will not be exact but should provide order of magnitude prices for the different phases of the project. If an outside consulting firm is assisting with this document, it can draw from experience with similar projects with like-sized companies. Because no two projects are ever the same, there needs to be some flexibility in these estimates. Typically, ranges for each phase should be provided.

Windows Server 2003 Design Decisions

As the previous section mentioned, the key Windows Server 2003 design decisions should be recorded in the design document. This is perhaps the most important section of the document because it will define how Windows Server 2003 will be configured and how it will interact with the network infrastructure.

Decisions should have been made about the hardware and software needed for the migration. They should take into account whether the existing hardware will be used in the migration, upgraded, left in place, or retired. This decision, in turn, will determine how many server software licenses will be required, which will directly affect the costs of the project.

The level of redundancy and security the solution will provide should be detailed. Again, it is important to be specific when talking about data availability and discussing the situations that have been planned for in the design.

The server and other infrastructure hardware and software should be defined in this section. If upgrades are needed for existing hardware (more processors, RAM, hard drives, tape drives, and so on) or the existing software (upgrades from the existing NOS, server applications, and vertical market applications), they should be detailed here.

Other key technologies such as messaging applications or industry-specific applications will be included here, in as much detail as appropriate.

Agreeing on the Design

The final step in the design document process actually takes place after the document has been created. When the document is considered complete, it should be presented to the project stakeholders and reviewed to make sure that it does, in fact, meet their requirements, that they understand the contents, and to see whether any additional concerns come up that weren't addressed in the document.

Although it is unlikely that every goal of every stakeholder will be met (because some may conflict), this process will clarify which goals are the most important and can be met by the technologies to be implemented.

Specific decisions made in the design document that should be reviewed include any disparities between the wish lists the stakeholders had and what the final results of the project will be. Also, the timeline and high-level budget should be discussed and confirmed. If the design document outlines a budget of $500K for hardware and software, but the stakeholders won't be able to allocate more than $250K, the changes should be made at this point, rather than after the migration document is created. A smaller budget may require drastic changes to the design document because capabilities in the solution may need to be removed, which will have ripple effects throughout the project.

If the time frame outlined in the design document needs to be modified to meet the requirements of the stakeholders, this should be identified prior to expending the effort of creating the detailed implementation plan as well.

Bear in mind as well that the design document can be used for different purposes. Some companies want the design document to serve as an educational document to inform not only what the end state will look like, but why it should be that way. Others simply need to document the decisions made and come up with budgetary information.

Having this level of detail will also make it easier to get competitive bids on the costs to implement. Many organizations make the mistake of seeking bids for solutions before they even know what the solution will consist of.


The Migration Planning Phase: Documenting the Process for Migration

Before the migration document is created, the end state of the project has been documented in detail and agreed upon by the key stakeholders in the organization. There should not be any question as to exactly what the next evolution of the network will be composed of and what functionality it will offer. In addition, an estimated budget for the hardware and software required and an estimated timeline for the project have been identified. In some cases, depending on the size and complexity of the project, and whether outside consulting assistance has been contracted, a budget has also been established for the implementation services.

So, now that the end state has been clearly defined, the migration document can be created to document the details of the steps required to reach the end state with minimal risk of negative impact to the network environment. The migration plan should not contain any major surprises.

A key component of the migration document is the project plan, or migration plan, that provides a list of the tasks required to implement the solution. It is the roadmap from which the migration document will be created. The migration document will also provide a narrative, where needed, of the specifics of the tasks that the project plan does not provide, and provide other details as outlined next.

Time for the Project Plan

As mentioned previously, the primary stepping stones needed to reach the end point have been sketched out in the discovery process, and in collaboration sessions or design discussions that have taken place. The project plan in the migration document provides a tool to complement the design document, which graphically illustrates the process of building and testing the technologies required as well as provides an outline of who is doing what during the project.

By using a product such as Microsoft Project, you can organize the steps in a logical, linear process. The high-level tasks, like those shown in Figure 2.1, should be established first. Typically, they are the phases or high-level tasks involved in the project, such as Lab Testing, Pilot Implementation, Production Implementation, and Support. Then the main components of these tasks can be filled in.

Figure 2.1. High-level migration project plan.

[View full size image]

Dates and durations should be included in the project plan, using the basic concept of starting with the end date when everything needs to be up and running, and then working backward. It's important to include key milestones, such as acquiring new software and hardware, sending administrative resources to training classes, and provisioning new data circuits. Slack time should also be included for unexpected events or stumbling blocks that may be encountered. Each phase of the project needs to be outlined and then expanded, similar to the sample prototype testing phase plan shown in Figure 2.2.

Figure 2.2. Sample Windows Server 2003 prototype testing phase project plan.

[View full size image]

Note that in the example in Figure 2.2, the tasks are kept on a high level, but additional details can be included as needed. A good rule of thumb is not to try to list every task that needs to take place during the phase, but to have each line represent several hours or days of work. If too much detail is put into the project plan, it quickly becomes unmanageable. For the detailed information that does not necessarily need to be placed in the project plan (Gantt chart), the information can be detailed in the migration document. The migration document adds in technical and operational details that will help clarify more specific project information.

Note

The terms project plan and Gantt chart are commonly interchanged in IT organizations and may or may not have different meanings to different individuals. In this book, the term project plan will refer to the chronological steps needed to successfully plan, prepare, and implement Windows Server 2003. The term Gantt chart will be used to refer to the chronological steps, but also the inclusion of resource allocation, start and end dates, and cost distribution.

The plan should also assign resources to the tasks and start to define the teams that will work on the different components of the project. If an outside organization is going to assist in the process, it should be included at the appropriate points in the project. Microsoft Project offers an additional wealth of features to produce reports and graphical information from this plan; they will prove extremely helpful when the work starts. Also, accurate budgetary information can be extracted, which can take into account overtime and after-hours rates and easily give "what if" scenario information.

Speed Versus Risk

The project plan will also enable you to test "what if" scenarios. When the high-level tasks are defined, and the resources required to complete each task are also defined, you can easily plug in external contractors to certain tasks and see how the cost changes. After-hours work might take place during working hours in certain places.

If the timeline still isn't acceptable, tasks can be stacked so that multiple tasks occur at the same time, instead of one after the other. Microsoft Project also offers extensive tools for resource leveling to make sure that you haven't accidentally committed a resource to 20 hours of work in a day.

The critical path of the project should be defined as well. Certain key events will need to take place for the project to proceed beyond a certain point. Ordering the hardware and having it arrive will be one of these steps. Getting stakeholder approval on the lab environment and proving that key network applications can be supported may well be another. Administrative and end-user training may need to happen to ensure that the resulting environment can be effectively supported.

You may need to build contingency time into the project plan as well. Hardware can get delayed and take an extra week or two to arrive. Testing can take longer, especially with complex configurations, and where customization of the NOS is required or directory information needs to be modified.

Creating the Migration Document

The migration document can now narrate the process detailed in the project plan. The project plan does not need to be 100% complete, but the order of the steps and the strategies for testing and implementing will be identified.

The following is a sample table of contents and brief description of the migration document:

  • Executive Summary Provides a brief discussion of the process of the Windows Server 2003 implementation (how pieces of the puzzle will fit together).

  • Goals and Objectives Includes the objectives specific to the migration process.

  • Roles and Responsibilities Outlines the members of the different teams that will be performing the work and should include internal as well as external resources.

  • Approach Breaks out the phasestypically prototype, pilot, implementation, and supportto define the steps (and key milestones) of the migration project.

  • Project Plan Provides a graphical representation of the components of the project, created in Microsoft Project or a similar product.

  • Detailed Budget Estimate Provides a summary of the costs based on the approach, resources, and durations for each task.

The Executive Summary

The executive summary should set the stage and prepare the audience for what the document will contain, and it should be concise. It should outline, at the highest level, what the scope of the work is. Ideally, the executive summary also positions the document in the decision-making process and clarifies that approvals of the design are required to move forward.

The Goals and Objectives Section

The goals and objectives section may seem redundant because the design documents documented the objectives in great detail, but it is important to consider which specific goals and objectives are important to the success of the migration project that may not have been included in the design document. For example, although the design document outlined what the final server configuration will look like, it may not have outlined the tools needed to migrate key user data or the order that the company offices will be migrated. So, the goals and objectives in the migration document will be very process specific.

The Roles and Responsibilities Section

In the roles and responsibilities section, the teams that will do the work should be identified in detail. If an outside company will be performing portions of the work, which tasks it will be responsible for and which ones internal resources will take ownership of should be documented.

The Approach Section

Each section of the approach should detail the goals of each phase, as well as the process that will be followed for that phase, and the resources and estimated durations. Information should also be provided on what the final deliverables from each phase will be and the sign-off criteria to consider the phase complete. Critical path tasks and the risks associated with specific tasks should be outlined in these sections as well.

Whereas the design document tells the story of the project's goals and the end state, the migration document provides the details of how to get there. It is important to note that the migration document is not typically a step-by-step guide on how to install and configure every product needed for the Windows Server 2003 project because such documents take an extraordinary amount of time to produce.

The design document can be referenced as appropriate in the migration document, or additional details can be provided to clarify the process.

The Project Plan Section

Where the project plan provides the high-level details of the steps, or tasks, required in each phase, the approach sections of the migration document can go into more detail about the details of each step of the project plan, as needed. Certain very complex tasks are represented with one line on the project plan, such as "Configure Windows Server 2003 #1" and may take several pages to describe in sufficient detail in the migration document.

Data availability testing and disaster recovery testing should be discussed. In the design document, you might have decided that clustering will be used, as well as a particular tape backup program, but the migration plan should outline exactly which scenarios should be tested in the prototype lab environment.

Documents to be provided during the migration should be defined so that it is clear what they will contain.

The Budget Section

With regards to the budget information, although a great amount of thought and planning has gone into the design and migration documents, as well as the project plan, there are still variables. No matter how detailed these documents are, the later phases of the project may change based on the results of the earlier phases. For instance, the prototype testing may go flawlessly, but during the pilot implementation, performing data migration simply takes longer than anticipated; this extra time will require modifications to the amount of time required and the associated costs. Note that changes in the opposite direction can happen as well, if tasks can occur more quickly than anticipated. Often the implementation costs can be reduced by keeping an eye on ways to improve the process during the prototype and pilot phases.


The Prototype Phase: Creating and Testing the Plan

The main goal of the prototype phase is to create a lab environment in which the key elements of the design as defined in the design document can be configured and tested. Based on the results of the prototype, you can determine whether any changes are needed to the implementation and support phases as outlined in the migration document.

The prototype phase is also a training phase, in which the members of the deployment team get a chance to get their hands dirty with the new hardware and software technologies to be implemented. If an external consulting firm is assisting with the prototype testing, knowledge transfer should occur and be expected during this process. Even if the deployment team has attended classroom training, the prototype process is an environment that will more closely reflect the end state of the network that needs to be supported, and will involve technologies and processes not typically covered in classroom-style training. The deployment team can also benefit from the real-world experience of the consultants if they are assisting in this phase.

This environment should be isolated from the production network so that problems created by or encountered in the process don't affect the user community.

The design details of testing applications, confirming hardware performance, testing fault tolerance failover, and the like should be verified in a safe lab environment. If changes are needed to the design document, they should be made now.

How Do You Build the Lab?

Although the details of the project will determine the specifics of exactly what will be in the prototype lab, certain common elements will be required. The migration document should clearly outline the components of the lab and what applications and processes should be tested. A typical environment will consist of the primary Windows Server 2003 required for the implementation, as well as network switches, sample workstations, and printers from the production environment. Connectivity to the outside world should be available for testing purposes.

A key decision to make is whether the lab will be implemented into the environment or stay as a lab. Some companies will proceed from the prototype phase to the pilot phase with the same equipment, whereas others prefer to keep a lab set up for future use. The advantages of having a lab environment for a Windows Server 2003 environment are many, and include testing NOS and application updates, upgrades and patches, as well as having hardware available for replacement of failed components in the production environment.

Real data and applications should be installed and tested. Data can be copied from live production servers, or data from tape can be restored to the test server. Applications should be installed on the servers according to a manufacturer's installation instructions; however, compatibility validation with Windows Server 2003 should be conducted as outlined in Chapter 18, "Compatibility Testing for Windows Server 2003."

After the software applications have been installed, representative users from the different company departments could be brought into the lab to put the applications through their paces. These users will be best able to do what they normally do in the lab environment to ensure that their requirements will be met by the new configuration. Areas that don't meet their expectations should be recorded and identified as either "show stoppers" that need to be addressed immediately or issues that won't harm the implementation plan.

Results of the Lab Testing Environment

A number of things come out of the lab testing process, besides the valuable learning that takes place. If time permits, and there is room in the budget, a variety of documents can be produced to facilitate the pilot and implementation process. Another key result of the lab is hard evidence of the accuracy and completeness of the design and migration documents.

Some of the documents that can be created will assist the deployment team during the migration process. One key document is the "As Built" document, which provides a snapshot of the key configuration details of the primary servers that have been configured and tested. Whereas the design document outlines many of the key configuration details, the "As Built" document contains actual screenshots of the server configurations as well as the output from the Windows Server 2003 Computer Management administrative tool that provides important details such as physical and logical disk configuration, system memory and processor information, services installed and in use on the system, and the like.

Another important document is the disaster recovery document (or DR document). This document should outline exactly which types of failures were tested, and the process for rectifying these situations. Keep in mind that a complete disaster recovery plan should include offsite data and application access, so the DR document that comes out of the prototype phase will in most cases be more of a hardware failure document that discusses how to replace failed components such as hard drives or power supplies, and how to restore the server configuration from tape backup or restore data sets.

If you need to implement multiple servers in the pilot and implementation phases, you can document checklists for the step-by-step processes in the prototype phase. Bear in mind that creating step-by-step documents takes a great deal of time (and paper!), and a change in process requires drastic changes to these documents. Typically, creating a step-by-step "recipe" for server builds is not worth the time unless lower-level resources need to build a large number in a short period of time.

When the testing is complete, the migration plan should be revisited to make sure that the timeline and milestones are still accurate. Ideally, there should be no major surprises during the prototype phase, but adjustments may be needed to the migration plan to ensure the success of the project.

Depending on the time frame for the pilot and implementation phases, the hardware and software that will be needed for the full implementation might be ordered at this point. As the cost of server hardware has decreased over the past several years, many companies "over-spec" the hardware they think they need, and they may determine during the prototype phase that lesser amounts of RAM or fewer processors will still exceed the needs of the technologies to be implemented, so the hardware requirements may change.


The Pilot Phase: Validating the Plan to a Limited Number of Users

Now that the prototype phase has been completed, the deployment team will be raring to go and have hands-on experience with all the new technologies to be implemented. The process documented in the migration document and migration plan will have been tested in the lab environment as completely as practical, and documentation detailing the steps to be followed during the pilot implementation will be at hand.

Although the pilot process will vary in complexity based on the extent of the changes to be made to the network infrastructure, the process should be well documented at this point.

It is important to identify the first group of users who will be moved to the new Windows Server 2003 environment. Users with a higher tolerance for pain are a better choice than the key stakeholders, for the most part.

Note

In many organizations, the CEO, CIO, VP of Sales, or other key executives may want to be part of the initial pilot rollout; however, we suggest not making these individuals part of the initial rollout. These individuals typically have the most complex user configuration with the lowest tolerance for interruption of network services. Users in the production environment with simpler needs can be used for the initial pilot. If necessary, create a pre-pilot phase so that the senior executives can be part of the official pilot phase, but don't make the challenges of pilot testing more difficult by starting with users who have the most complex needs.

A rollback strategy should be clarified, just in case. Test the disaster recovery and redundancy capabilities thoroughly at this point with live data but a small user group to make sure everything works as advertised. Migration processes can be fine-tuned during this process, and time estimates can be nailed down.

The First Server in the Pilot

The pilot phase is begun when the first Windows Server 2003 accessed by users is implemented in the production environment. Dependent on the scope of the migration project, this first server may be a simple application server running Terminal Services or SharePoint Team Services, or the first server may be the root of the Active Directory tree.

Just as in the prototype phase, the testing to be conducted in the pilot phase is to verify successful access to the server or application services the system provides. One of the best ways to validate functionality is to take the test sequences used in the prototype phase and repeat the test steps in the pilot production environment.

The major difference between the prototype and pilot phases is interconnectivity and enterprisewide compatibility. In many lab-based prototype phases, the testing is isolated to clean system configurations or homogeneous system configurations; however, in a pilot production environment, the new technology is integrated with old technology. It is the validation that the new setup works with existing users, servers, and systems, and software is the added focus of the production pilot phase.

Rolling Out the Pilot Phase

The pilot phase is usually rolled out in sub-phases, with each sub-phase growing in number of users affected, uses of system technology by the pilot users, and the distribution of users throughout the organization.

Quantity of Pilot Users

The whole purpose of the pilot phase is to slowly roll out users throughout the organization to validate that prototype and test assumptions were accurate and that they can be successful in the production environment. An initial group of 5 to 10 pilot users (typically members of the IT department overseeing and managing the migration) are first to be migrated. These users test basic functionality.

After successful basic testing, the pilot users group can grow to 1%, then to 3%, on to 5%, and finally to 10% of the user base in the organization. This phased rollout will help the migration team test compatibility, inner-communications, and connectivity with existing systems, while working with a manageable group of users that won't overwhelm the help desk services in place during the pilot and migration process.

The pilot phase is also a time when help desk and migration support personnel build the knowledge base of products that occur during the migration process so that if or when problems occur again (possibly in the full rollout phase of the product), lessons have been learned and workarounds already created to resolve stumbling blocks.

Application Complexity of Pilot Users

In addition to expanding the scope of the pilot phase by sheer quantity, selecting users who have different application usage requirements can provide a level of complexity across software platforms. Application compatibility and operation are critical to the end user experience during the migration process. Often users won't mind if something runs a little slower during the migration process or that a new process takes a while to learn; however, users will get upset if the applications they require and depend on each day to get their job done lock up while they use the application, data is lost due to system instability, or the application just won't work. So testing applications is critical in the early pilot phase of the project.

Role Complexity of Pilot Users

Pilot users should also be drawn from various roles throughout an organization. In many migrations, all pilot users are tested from a single department using just a single set of applications, and it isn't until the full migration process that a feature or function that is critical to everyone in the organization (except the pilot group user's department) doesn't work. An example might be a specific financial trading application, a proprietary healthcare tracking application, or a critical sales force automation remote access tool that causes the entire project to come to a halt far into the full rollout phase.

Geographical Diversity of Pilot Users

The pilot group should eventually include members geographically distributed throughout the organization. It is important to start the pilot phase with a set of users who are local to the IT or help desk operation so that initial pilot support can be done in person or directly with the initial pilot group. Before the pilot is considered complete, however, users from remote sites should be tested to ensure their user experience to the new networking environment hasn't been negatively affected.

Fixing Problems in the Pilot Phase

No matter how much planning and testing are conducted in the earlier phases of the project, problems always crop up in the pilot phase of the project. It is important to have the prototype lab still intact so that any outstanding problems can be re-created in the lab, tested, and resolved to be tested in the pilot production phase again.

Documenting the Results of the Pilot

After the pilot, it is important to document the results. Even with the extensive discovery and design work, as well as the prototype lab testing and pilot phases that have taken place, problems may reoccur in the post-pilot phases, and any documented information on how problems were resolved or configurations made to resolve problems in the pilot phase will help simplify the resolution in future phases. If you take some extra time to give attention to the pilot users, you can fine-tune the solution to make sure the full implementation is a success.


The Migration/Implementation Phase: Conducting the Migration or Installation

By this point in the project, more than 10% of the organization's users should have been rolled out and tested in the pilot phase, applications thoroughly tested, help desk and support personnel trained, and common problem resolution clearly documented so that the organization can proceed with the migration and installation throughout the rest of the organization.

Verifying End User Satisfaction

A critical task that can be conducted at this point in the project is to conduct a checkpoint for end user satisfaction, making sure that users are getting their systems, applications, or functionality upgraded; questions are answered; problems are resolved; and most importantly, users are being made aware of the benefits and improvements of the new environment.

Not only does this phase of the project focus on the rollout of the technology, but it is also the key public relations and communications phase of the project. Make sure the user community gets the training and support it needs throughout the process. Plan on issues arising that will need support for several days after each department or user group is upgraded. Don't forget the special users with unique requirements and remote users because they will require additional support.

Supporting the New Windows Server 2003 Environment

Before the last users are rolled into the new networking environment, besides planning the project completion party, you need to allocate time to ensure the ongoing support and maintenance of the new environment is being conducted. This step not only includes doing regular backups of the new servers (covered in detail in Chapter 32, "Backing Up a Windows Server 2003 Environment"), but also includes planning for regular maintenance (Chapter 22, "Windows Server 2003 Management and Maintenance Practices"), monitoring (Chapter 25, "Integrating Microsoft Operations Manager with Windows Server 2003"), and tuning and optimization (Chapter 35, "Capacity Analysis and Performance Optimization") of the new Windows Server 2003 environment.

Now is the time to begin planning for some of the wish list items that didn't make sense to include in the initial migrationfor example, a new antiviral solution, knowledge-management solutions, enhanced security, and so on. If you have a lab still in place, use it for testing patches and software updates.


Summary

One analogy used in this chapter is that of building a house. Although this analogy doesn't stand up to intense scrutiny, the similarities are helpful. When an organization is planning a Windows Server 2003 implementation, it is important to first understand the goals for the implementation, and not only the "50,000-foot" high-level goals, but also the "10,000-foot" departmental and "1,000-foot" IT staff goals. Then it is important to more fully understand the environment that will serve as the foundation for the upgrade. Whether this work is performed by external resources or by internal resources, a great deal will be learned about what is really in place, and where there might be areas of risk or exposure. Collaboration sessions with experienced and effective leadership can then educate the stakeholders and deployment resources about the technologies to be implemented as well as guide the group through the key decisions that need to be made. Now all this information needs to be documented in the design document so that the details are clear, and some initial estimates for the resources required, timeline, and budget can be set. This document serves as a blueprint of sorts, and defines in detail what the "house" will look like when it is built. When all the stakeholders agree that this is exactly what they want to see, and the timeline and budget are in line, the migration document can be produced.

The migration document includes a detailed project plan that provides the tasks that need to take place to produce the results detailed in the design document. The project plan should not go into step-by-step detail describing how to build each server, but should stick to summary tasks from four hours to a day or more in duration. The migration document then provides a narrative of the project plan and supplies additional information pertaining to goals, resources, risks, and deliverables, as well as budgetary information accurate in the 10 to 20% range.

Based on these documents, the organization can now proceed with building the solution in a lab environment and testing the proposed design with actual company data and resources involved. The results of the testing may require modifications to the migration document, and will prepare the deployment team for live implementation. Ideally, a pilot phase with a limited, noncritical group of users, will occur, to fine-tune the live implementation process and put in place key technologies and Windows Server 2003. Now the remainder of the implementation process should proceed with a minimum of surprises, and the result will meet the expectations set in the design phase and verified during the prototype and pilot phases.

Even the support phase has been considered, and during this phase, the "icing on the cake" can be applied as appropriate. Although this process may seem complex, it can be molded to fit all different sizes of projects and will yield better results.


Best Practices

  • Use a migration methodology consisting of discovery, design, testing, and implementation phases to meet the needs of your organization.

  • Fully understand the business and technical goals and objectives of the upgrade and the breadth and scope of benefits the implementation will provide before implementing a new application or upgrade.

  • Create a scope of work detailing the Windows Server 2003 network functionality, data management, information access, and application hosting.

  • Define high-level organizational and departmental goals.

  • Determine which components and capabilities of the network are most important and how they contribute to or hinder the goals expressed by the different units.

  • Clearly define the technical goals of the project on different levels ("50,000-foot," "10,000-foot," "1,000-foot," and so on).

The Discovery Phase

  • Review and evaluate the existing environment to make sure the network foundation in place will support the new Windows Server 2003 environment.

  • Make sure the existing environment is configured the way you think it is, and identify existing areas of exposure or weakness in the network.

  • Define the current network stability and performance measurements and operation.

  • Use external partners to produce more thorough results due to their extensive experience with network reviews and analysis and predict the problems that can emerge midway through a project and become "show stoppers."

  • Start the discovery process with onsite interviews.

  • Review and evaluate every affected device and application to help determine its role in the new environment.

  • Maintain and protect database information that is critical to an organization on a regular basis.

  • Determine where data resides, what file stores and databases are out there, how the data is maintained, and whether it is safe.

The Design Phase

  • Create a design document including the salient points of the discussion, the reasons the project is being invested in, the scope of the project, and the details of what the results will look like.

  • Create a migration document providing the roadmap showing how the end state will be reached.

  • Use a consultant with hands-on experience designing and implementing Windows Server 2003 to provide leadership through this process.

  • Determine what hardware and software will be needed for the migration.

  • Determine how many server software licenses will be required to more accurately calculate project costs.

  • Detail the level of redundancy and security that is required and that the solution will ultimately provide.

  • Present the design and migration documents to the project stakeholders for review.

The Migration Planning Phase

  • Create a migration document containing the details of the steps required to reach the end state with minimal risk or negative impact to the network environment.

  • Create a project plan that provides a list of the tasks, resources, and durations required to implement the solution.

The Prototype Phase

  • Create a lab environment in which the key elements of the design as defined in the design document can be configured and tested.

  • Isolate the lab environment from the production network so that any problems created or encountered in the process don't affect the user community.

  • Thoroughly test all applications.

The Pilot Phase

  • Identify the first group of users who will be moved to the new Windows Server 2003 environment. Users with a higher tolerance for pain are a better choice than the key stakeholders, for the most part.

  • Clarify a rollback strategy, just in case unexpected problems occur.

  • Test the disaster recovery and redundancy capabilities thoroughly.

  • Fine-tune the migration processes and nail down time estimates.

The Migration/Implementation Phase

  • Verify that applications have been thoroughly tested, help desk and support personnel have been trained, and common problem resolution is clearly documented.

  • Conduct a checkpoint for end user satisfaction.

  • Allocate time to ensure that ongoing support and maintenance of the new environment are being conducted before the last users are rolled into the new networking environment.

  • Plan a project completion party.


Chapter 3. Installing Windows Server 2003

In This Chapter

  • Preplanning and Preparing a Server Installation

  • Setting Up the Windows Server 2003 Operating System

  • Upgrading to Windows Server 2003

  • Using Alternative Methods of Installation

  • Performing an Unattended Windows Server 2003 Installation

  • Installing Windows Server 2003 from an Image

  • Installing Windows Server 2003 with Group Policy and Systems Management Server

  • Updating a Windows 2003 Server with a Service Pack

  • Preparing a System and Installing the Windows 2003 R2 Components

This chapter describes the process for installing the Microsoft Windows Server 2003 operating system (32-bit and 64-bit), Windows 2003 Service Packs, and the Windows 2003 R2 update. With the advances in Microsoft technologies over the years, many steps in the installation process have been simplified. For example, you still must verify that your hardware is supported by the operating system, but the Plug and Play capability of the application automatically detects and configures most hardware items. Thankfully, the days of determining the IRQ, base I/O address, and memory range of your system devices are, for the most part, in the past. In fact, Windows Server 2003 has the easiest and most intuitive installation procedure of any Microsoft operating system to date.

The server, however, will not install itself. You still must make several decisions to ensure that your completed installation will meet your needs. This chapter walks you through these key decisions and helps you make the correct choices for your environment.


Preplanning and Preparing a Server Installation

Before you begin the actual installation of Windows Server 2003, you must make several decisions. How well you plan these steps will determine how successful your installation is.

Verifying Minimum Hardware Requirements

The first step of the installation is verifying that your hardware meets the system requirements. Keep in mind that, although there is a minimum requirement for the CPU and RAM, there is also a recommended CPU and RAM configuration. For the sake of performance, you should usually stay away from the minimum requirements and stick to the recommended settings (or better). Table 3.1 lists system recommendations for Windows Server 2003 (32-bit), and Table 3.2 lists system recommendations for Windows Server 2003 (x64-bit edition).

Table 3.1. System Requirements (32-bit)

Requirement

Standard Server

Enterprise Server

Minimum CPU speed

133MHz

133MHz for x86-based computers

733MHz for Itanium-based computers

Recommended CPU speed

550MHz

733MHz

Minimum RAM

128MB

128MB

Maximum RAM

4GB

32GB

Multiprocessor support

Up to 4

Up to 8

Disk space

1.5GB

1.5GB

Table 3.2. System Requirements (x64-bit)

Requirement

Standard Server

Enterprise Server

Supported Processors

AMD Opteron, AMD Athlon 64, Intel Xeon with Intel EM64T, and Intel Pentium with Intel EM64T

Minimum RAM

512MB

512MB

Maximum RAM

32GB

1TB

Multiprocessor support

Up to 4

Up to 8

Disk space

4GB

4GB

Choosing a New Installation or an Upgrade

If you have an existing Windows environment, you may need to perform a new installation or upgrade an existing server. There are benefits to each of these options.

Should You Perform a New Installation?

The primary benefit of a new installation is that, by installing the operating system from scratch, you are starting with a known good server. You can avoid migrating problems that may have existed on your previous serverwhether due to corrupt software, incorrect configuration settings, or improperly installed applications. Keep in mind, however, that you will also lose all configuration settings from your previous installation. Make sure you document your server configuration information and back up any data that you want to keep.

When performing a new installation, you can install on a new hard drive (or partition) or in a different directory on the same disk as a previous installation. Most new installations are installed on a new or freshly formatted hard drive. Doing so removes any old software and gives you the cleanest installation.

Should You Upgrade an Existing Server?

Upgrading, on the other hand, replaces your current Windows files but keeps existing users, settings, groups, rights, and permissions. In this scenario, you don't have to reinstall applications or restore data. Before choosing this option, keep in mind that you should test your applications for compatibility before migration. Just because they worked on previous versions of Windows does not mean they will work on Windows Server 2003.

As always, before performing any type of server maintenance, you should perform a complete backup of any applications and data that you want to preserve.

To upgrade to Windows Server 2003, you must be running a server-level operating system. You cannot upgrade Workstation or Home editions to Windows Server 2003. To upgrade your existing server, you must be running Windows 2000 or Windows NT 4.0 Server (Service Pack 5 or higher). Table 3.3 lists the available upgrade paths to Windows Server 2003.

Table 3.3. Upgrade Compatibility for Windows Server 2003

Previous Operating System

Upgrade to Windows Server 2003 Possible?

Windows NT versions 3.51 and earlier

No, you must first upgrade to NT 4.0 Service Pack 5 or higher.

Windows NT 4.0 Server

Yes, you must have Service Pack 5 or higher.

Windows 2000 Server

Yes.

Windows 2000 Advanced Server

Yes.

Windows 2000 Professional

No, only server-level operating systems can be upgraded.

Windows XP Professional

No, only server-level operating systems can be upgraded.

Novell NetWare

No, but migration tools are available to migrate Novell Directory Services (NDS) information to a Windows domain.

Note

When considering installing or updating to Windows 2003 R2, the R2 update merely adds components on top of an existing Windows 2003 SP1 or higher server configuration. Windows 2003 R2 is not a new or separate operating system. Therefore, when referencing the upgrade of Windows, this chapter refers to the upgrade from Windows NT4 or Windows 2000 to Windows 2003, and not from Windows 2003 to Windows 2003 R2.

Determining the Type of Server to Install

You have the choice of making your server a domain controller (DC), a member server, or a standalone server. After you determine the tasks the server will perform, you can determine the role you will assign to it.

Domain controllers and member servers play a role in a new or existing domain. Standalone servers are not joined to a particular domain.

As in Windows 2000, you are able to promote or demote server functions as you like. Standalone servers can be joined to the domain to become member servers. Using the DCPromo utility, you can promote member servers to domain controllers. And, by uninstalling the Active Directory service from a domain controller, you can return it to member server status.

Gathering the Information Necessary to Proceed

During the installation of Windows Server 2003, you will have to tell the Setup Wizard how you want your server configured. The wizard will take the information you provide and will configure the server settings to meet your specifications.

Taking the time to gather the information described in the following sections before starting your installation will likely make your installation go faster and easier.

Selecting the Computer Name

Each computer on a network must have a name that is unique within that network. Many companies have a standard naming convention for their servers and workstations. If not, you can use the following information as a guideline for creating your own. Although the computer name can contain up to 63 characters, workstations and servers that are preWindows 2000 recognize only the first 15 characters. It is widely considered a best practice to use only Internet-standard characters in your computer name. This includes the letters AZ (upper- and lowercase), the numbers 09, and the hyphen (-).

Although it's true that implementing the Microsoft domain name system (DNS) service in your environment could allow you to use some non-Internet standard characters (such as Unicode characters and the underscore), you should keep in mind that this is likely to cause problems with any non-Microsoft DNS servers on your network. You should think carefully and test thoroughly before straying from the standard Internet characters noted in the preceding paragraph.

Name of the Workgroup or Domain

During the server installation, the Setup Wizard will ask for the name of the workgroup or domain that the server will be joining. You can either enter the name of an existing organizational structure or enter a new name, creating a new workgroup or domain.

Users new to Microsoft networking may ask, "What is the difference between a workgroup and a domain?" Simply put, a domain is a collection of computers and supporting hardware that share the same security database. Grouping the equipment in this manner allows you to set up centralized security and administration. Conversely, a workgroup has no centralized security or administration. Each server or workstation is configured independently and locally for all security and administration settings.

Network Protocol and IP Address of the Server

When installing Windows Server 2003, you must install and configure a network protocol that will allow it to communicate with other machines on the network. Currently, the most commonly used protocol is called TCP/IP, which stands for Transmission Control Protocol/Internet Protocol. This protocol allows computers throughout the Internet to communicate. After you install the TCP/IP protocol, you need to configure an IP address for the server. You can choose one of the following three methods to assign an IP address:

  • Automatic Private IP Addressing (APIPA) APIPA can be used if you have a small network that does not have a Dynamic Host Configuration Protocol (DHCP) server, which is used for dynamic IP addresses. A unique IP address is assigned to the network adapter using the LINKLOCAL IP address space. The address always starts with 169.254 and is in the format 169.254.x.x. Note that if an APIPA is in use, and a DHCP server is brought up on the network, the computer will detect this and will use the address that is assigned by the DHCP service instead.

  • Dynamic IP address A dynamic IP address is assigned by a DHCP server. This allows a server to assign IP addresses and configuration information to clients. Some examples of the information that is distributed include IP address, subnet mask, default gateway, domain name system (DNS) server address, and Windows Internet Naming Service (WINS) server address. As the dynamic portion of the name suggests, this address is assigned to the computer for a configurable length of time, known as a lease. When the lease expires, the workstation must again request an IP address from the DHCP server. It may or may not get the same address that it had previously. Although servers and workstations can both be configured to use this method of addressing, it is generally used for workstations rather than servers.

  • Static IP address Using a static IP address is the most common decision for a server configuration. By static, we mean that the address will not change unless you change the configuration of the server. This point is important because clients and resources that need to access the server must know the address to be able to connect to it. If the IP address changed regularly, connecting to it would be difficult.

Backing Up Files

Whether you are performing a new installation on a previously used server or upgrading an existing server, you should perform a complete backup of the data and operating system before you begin your new installation. This way, you have a fallback plan if the installation fails or the server does not perform the way you anticipated.

When performing a new installation on a previously used server, you overwrite any data that was stored there. In this scenario, you will have to use your backup tape to restore any data that you want to preserve.

On the other hand, if you are going to upgrade an existing server, a known good backup will allow you to recover to your previous state if the upgrade does not go as planned.

Note

Many people back up their servers but never confirm that the data can be read from the backup media. When the time comes to recover their data, they find that the tape is unusable or unreadable, or that they do not know the proper procedures for restoring their server. You should perform backup/recovery procedures on a regular basis in a lab environment to make sure that your equipment is working properly and that you are comfortable with performing the process.


Setting Up the Windows Server 2003 Operating System

If you have installed Microsoft server operating systems before, you will be familiar with the look and feel of the Windows Server 2003 installation process. The familiar blue background with white text is still there for the first half of the installation and, for the most part, the questions are the same. You still have to press F8 to accept the license agreement, but unlike with some older versions, you aren't required to page down to read the whole thing first anymore. The next step is to set up the hard drive and partitions you want to install to. Although the process is similar to previous versions, you have some new options to choose from. Follow the instructions to prepare and select your desired partition for installation.

Formatting the Partition

With older versions of the Windows operating system, you had two options when partitioning the hard drive: NTFS or FAT. You still have these familiar options, but two new ones for quick formatting have been added to the list, as shown in Figure 3.1.

Figure 3.1. Options for formatting the Windows Server 2003 partition.

[View full size image]

Quick Formatting or Regular Formatting

When you select NTFS or FAT to format the partition, the drive must be formatted. This process can take a significant amount of time.

The new "quick" option can format the partitions much fasterin some cases more than 25 times faster! But be aware, in this instance the drive is not being truly formatted. The Quick Format option performs only a high-level format of a diskusing the tracks and sectors already defined by an earlier formatting. This option is most helpful when you're installing servers that did not previously contain any confidential information. And it really comes in handy when you're installing a server over and over in the lab.

FAT or NTFS

One of the most commonly asked questions when installing a Windows-based server is, "Should I select FAT or NTFS?" FAT (which stands for file allocation table) has been around for a long timesince the days of MS-DOS. It was upgraded with Windows 95 SR-2, when FAT16 became FAT32, giving us the functionality of long filenames and allowing us to create larger disk and volume sizes.

Although the theoretical partition size with FAT32 is up to 2 terabytes, Windows Server 2003 places a limitation that allows volumes only up to 32GB in size. Your file sizes are also limited; no file can be larger than 4GB (2GB in FAT16).

There are two scenarios in which you would have to use the FAT file system. First, you use it if you are building Windows 2003 on a machine that will have to dual-boot to an operating system that does not support NTFS (such as Windows 95). And second, you use it if you want the ability to boot the server to a floppy disk (such as a DOS or Win95 boot disk) to access the files on the root partition.

Caution

Keep in mind, however, that if you can boot your server to a floppy to access the files stored on the hard drive, so can someone else!

NTFS (NT File System) is the recommended file system for use with Windows Server 2003, as it was for Windows 2000 and Windows NT servers. NTFS is actually NTFS5 and was upgraded with NT 4.0 Service Pack 4. This file system is less likely to become corrupt and is able to recognize errors and bad sectors of a hard drive. When one of these problems is discovered, the file system repairs itself automatically.

Windows Server 2003 allows supported volume sizes up to 16 terabytes (minus 4KB), and the maximum file size is 16TB (minus 64KB). Additionally, NTFS has better file security, disk compression, and encryption capabilities, and it can use fault-tolerant disk configurations such as mirroring and disk striping. So, which file system do you use for Windows Server 2003? The rule of thumb is if you don't have to use FAT for one of the reasons mentioned here, go with NTFS.

Customizing Regional and Language Options

After the boot partition is configured, all the operating system files will be copied there. The system will reboot, and the GUI portion of the installation will commence.

When customizing the Regional Options section, you can configure the Standards and Formats. These settings control how the workstation formats numbers, currencies, dates, and times. The Location setting provides you with local information, such as news and weather.

In the Languages section, you can modify the text services and input languages. Additionally, you can install supplemental language support for East Asian languages and support for complex script and right-to-left languages, including Thai.

Personalizing the Software

The Setup Wizard next asks for your name and that of your organization. This information is used during the setup to determine the default computer name. Additionally, it will be displayed on the Windows Server 2003 screen in the Registered To section.

Many companies have a policy in place detailing how these fields are to be filled out. A common practice is to put the department or location (such as Human Resources or Oakland) in the Name field and the name of the company in the Organization field.

Inserting a Product Key

If you have installed previous versions of the Windows operating systems, the process of inserting a product key will be familiar to you. In the past, server and workstation installations required the inserting of a product key to activate the software.

With Windows Server 2003, you still have to input a product key, but there are a few different scenarios. The Windows Server 2003 activation key initiative is described in the following sections.

Using a Retail Media Activation Key

When you purchase the installation media from a retail source, you will have to contact Microsoft (either online or by telephone) to activate your product key. This key is unique for each installation. Fortunately, you still can automate the installation by using technologies such as Windows Scripting Host (WSH) and Windows Management Instrumentation (WMI).

Using a Volume Media Activation Key

When you purchase the installation media as part of a Microsoft volume licensing program (such as Open or Select), no activation is required. Additionally, you will be able to use a common product key across all your installations.

Selecting Licensing Modes

Another point of confusion for many installers is the topic of licensing modes. When installing Windows Server 2003, as in Windows 2000 and NT, you must select one of two licensing modes for the server. You can specify Per Server or Per Device.

Note

If you are not sure which licensing mode to use for your environment, select Per Server. If necessary, you can make a one-time switch from Per Server to Per Device, but the licensing does not allow the reverse switch from Per Device to Per Server.

Per Server Licensing

In Per Server licensing mode, each server has a defined number of clients that are allowed to connect at any one time. Each server in the network that uses this mode must have enough client access licenses (CALs) purchased to cover the maximum number of concurrent connections the server is going to support. If the number of connections exceeds the configured number of CALs, clients may be locked out or receive Access Denied messages when they attempt to connect to network resources.

This option is typically selected by small companies with only one Windows Server 2003 system because smaller organizations have a smaller number of users. You may also want to select this option if you are configuring a Web server or Remote Access Service (RAS) server. You can configure the maximum number of users who will connect and, even if the client is not licensed as a Windows Server 2003 networking client, you are not breaking your licensing agreement.

Per Device Licensing

In the Per Device licensing mode, a CAL is required for each workstation (or seat) that connects to any licensed server. This includes users running any Windows operating system, Macintosh, or Unix computers connecting to a Windows file server.

In this scenario, a workstation is not limited to connecting to only one server; client computers are allowed access to any server within a Windows network, as long as each client machine is licensed with a CAL.

This is the most common licensing option because most companies have more than one server. Although the cost of a CAL is more expensive than a Per Server client license, you have to pay only once for that user to access an unlimited number of Windows-based servers.

Setting Computer Name and Administrator Password

Next, you are prompted to enter a computer name and administrator password for your computer.

Choosing Your Computer Name

By default, the setup program suggests a computer name based on the information you provided earlier in the Organization field of the Personalize Your Software section. You can (and, in most instances, should) change that default name here. Insert the name you decided on earlier in the "Gathering the Information Necessary to Proceed" section of this chapter.

Selecting an Administrator Password

The Setup Wizard automatically creates a default account for the administrator called, surprisingly enough, Administrator. This account has local administrative privileges and enables you to manage all local configuration settings for the server. For the sake of security, you can (and should) rename this account after you complete the installation.

You need to decide on a password for this account. You must enter it twicefirst in the Password box and then again in the Confirmation box.

As in previous Windows operating systems, the password is case sensitive and can contain up to 127 characters. You should choose your password carefully to ensure the security of the system.

If you enter a password that does not meet Microsoft's criteria for strong passwords, you will receive a Windows Setup warning, as shown in Figure 3.2.

Figure 3.2. Password strength warning during setup.

For security reasons, you should never choose a password that does not meet the minimum criteria listed.

Modifying Date and Time Settings

The next step is to set the correct date and time, and select the appropriate time zone for your location. Additionally, if your location uses daylight saving time, make sure the box for that option is checked. A dialog box may or may not pop up, depending on installed hardware.

Modifying Network Settings

Next, you need to decide on the appropriate network settings for the server. These settings configure your computer so that it can connect to other computers, networks, and the Internet. You can select either Typical Settings or Custom Settings.

Typical Settings

When you choose Typical Settings, the Setup Wizard automatically configures the default network settings for the server. These default settings include the installation of the Client for Microsoft Networks, file and print access, and TCP/IP as the default protocol. Additionally, when configuring the TCP/IP settings, the server searches for a DHCP server.

If it finds one, it will configure the server for a dynamic IP address. If no DHCP server is found, it will configure an Automatic Private IP Address (APIPA).

For most companies, the default client, services, and protocols selected will meet their needs, though you will likely want to change the TCP/IP settings and assign a static address for the server. See the earlier section "Network Protocol and IP Address of the Server" for more information.

Custom Settings

Selecting Custom Settings allows you to manually configure the networking components. By default, the Client for Microsoft Networks, File and Printer Sharing for Microsoft Networks, and Internet Protocol (TCP/IP) are selected.

If you want to install additional clients, services, and/or protocols, or if you want to change the default configuration for these selections, selecting the Custom Settings option may be in order.

Joining a Workgroup or Computer Domain

If you are joining an existing domain, you will need the login name and password for a domain administrator in that domain. Alternatively, you can have the administrator of the domain add your computer name into the domain so that your server can connect.

If you do not know the name of the domain that the server will be a member of, or if you do not have the administrative rights to join the server to the domain, select a workgroup installation. You can easily join the server to a domain at a later time.

Completing the Installation

After you click Next, the Setup Wizard will complete the installation of the server, apply all the configuration settings that you specified, and remove all temporary setup files. Upon completion, the computer will reboot and will load Windows Server 2003.

Logging In

When you're prompted, press Ctrl+Alt+Delete to log in to Windows Server 2003. The default administrator name should be displayed for you. You must type in the password that you assigned and click OK to continue.

Activating Windows Server 2003

If your copy of Windows Server 2003 needs to be activated, you can either click the icon in the system tray that looks like a pair of gold and silver keys, or you can choose Start, All Programs, Activate Windows. You have the choice of activating Windows via the Internet or by telephone.

Activating Windows over the Internet

To activate your system via the Internet, select that option and click Next. You then are asked whether you want to register with Microsoft. This step is optional and not required to activate Windows. If you register, Microsoft will (with your consent) notify you of product updates, new products, events, and special offers.

Selecting Yes, I Want to Register and Activate Windows at the Same Time brings you to the Collecting Registration Data screen, as shown in Figure 3.3.

Figure 3.3. Windows registration data collection screen.

[View full size image]

Fill out the required information and click Next to continue. This begins the activation process as your server verifies connectivity to the Internet. Selecting No, I Don't Want to Register Now; Let's Just Activate Windows starts the activation process as your server verifies connectivity to the Internet. After connectivity is verified, you will see a window that confirms your copy of Windows has been activated. Click OK to close the Activation Windows Wizard.

Activating Windows Server 2003 by Telephone

To activate Windows Server 2003 by telephone, select Yes, I Want to Telephone a Customer Service Representative to Activate Windows and click Next to continue. The Activate Windows Wizard quickly generates a new installation ID and continues to the next phase.

You are then instructed to select your location and are given a number to call. When you speak with the customer service representative, give him the installation ID that was automatically generated. The representative will then give you the confirmation ID to enter in step 4, shown in Figure 3.4.

Figure 3.4. Activating Windows Server 2003 by phone.

[View full size image]


Upgrading to Windows Server 2003

When upgrading to Windows Server 2003, all your configuration settings are retained from the previous installation. However, you still should complete several very important tasks before you perform the upgrade.

Backing Up the Server

As with any major change on your server, something could go wrong. A complete backup of your operating system and data can make the difference between an inconvenient rollback and a complete disaster.

Verifying System Compatibility

When you install the Windows Server 2003 CD-ROM into an existing server, the autorun feature should start the installation program. One of the options on the first page is Check System Compatibility. When you click this button, you have the choice of checking the system automatically or visiting the compatibility Web site.

Checking the System Automatically

When you check automatically, you next have the option to download any setup files that have been updated since your CD was released. The compatibility checker will connect to Microsoft via the Internet, download any updated software, and apply them to the setup upgrade.

Next, you will receive a report on the system compatibility. Any problems that Microsoft was able to detect will be shown here. An example would be that a service (such as IIS) will be disabled during the upgrade to prevent malicious attacks on the server. After you review the report, click Finish.

Performing Additional Tasks

Before proceeding with the installation, you can also select Perform Additional Tasks. These tasks enable you to set up a Remote Desktop Connection (RDC), browse the contents of the installation CD, and review the setup instructions and release notes.

Performing the Upgrade

At this point, your data is backed up, you have verified compatibility with the new operating system, and you have read the release notes. It's time to upgrade, so proceed with the following steps:

1. | Select Install Windows Server 2003, Enterprise Edition Server to begin the Windows Server 2003 Setup Wizard.
2. | From the setup screen, you need to select the installation type. Select Upgrade and click Next to continue.
3. | After reviewing the license agreement, select I Accept This Agreement and click Next to continue.
4. | If the installation media you are using require a product key, enter it here. The 25-character product key can be found on a sticker on the back of your Windows CD case. Enter the product key and click Next to continue.
5. | The Setup Wizard next checks your computer for compatibility with Windows Server 2003. You can review details about each item by clicking the Details button. Also, you can save the compatibility report by clicking the Save As button.
6. | After reviewing any discrepancies and ensuring that no show-stoppers exist on the list, click Next to continue.
7. | The Setup Wizard then finishes copying installation files and restarts the computer.

Note

After installing the core Windows operating system but before adding the server to the production network, make sure to install the latest Service Pack and apply the most current security updates.

The process of completing the installation and activating Windows is the same for an upgrade as it is for an initial installation.


Using Alternative Methods of Installation

Several alternative methods can be used to install Windows Server 2003. By using deployment tools such as Remote Installation Services (RIS), System Preparation (Sysprep), Remote Installation Preparation (RIPrep), Unattend files, and Group Policy (with Systems Management Server, or SMS), you can create images and scripts to match your server installation with various scenarios. Table 3.4 shows the available methods of installation.

Table 3.4. Deployment Tools and Their Uses

Unattend

RIS

Sysprep

GP/SMS

Basic installation

X

X

X

Upgrade

X

X

Dissimilar hardware

X

X

X

Image-based installation

X

X

Operating system and applications installed

X

X

X together

AD required

X

X

The following sections will give you some information about these other installation options.


Performing an Unattended Windows Server 2003 Installation

Using scripting, you can automate the installation process of Windows Server 2003 and minimize the need for user intervention. Using an answer file (unattend.txt), you can provide all the information needed to complete the installation. Items such as the computer name, IP address, product key, and DNS settings can be written into the file.

Unattended installations can be performed on fresh installations or on upgrades and on similar or dissimilar hardware. You can deploy Windows Server 2003 from a centralized installation point, and after you install the operating system, you can easily modify it.

Deciding When to Use an Unattended Installation

Organizations frequently use an unattended installation when they need to deploy multiple systems that are configured in a similar manner. Unlike imaging technologies, unattended installations work well with dissimilar hardware platforms. You can create one answer file, make a few modifications, and apply it to another server that you want configured similarly.

This process is also useful for deploying remote systems that need to be built onsite when you may not be able to configure it yourself. The system configured at the remote site will be configured just like you want it to be.

Using the Improved Setup Manager

The Setup Manager is located in the deploy.cab file in the \support\tools directory on the Windows product CD. The Setup Manager can be used to create and modify the answer files for your unattended installations.

Enhancements to the Setup Manager for Windows Server 2003 include the capability to encrypt the administrator password, which was formerly stored as plain text in the answer file. The Setup Manager also has an improved interface and an improved help file.

Preparing for an Unattended Installation

To prepare for an unattended installation, you must first install and run the Setup Manager. Although this application is included with the Windows Server 2003 installation media, it is not installed by default.

To install the Setup Manager, perform the following steps:

1. | Insert the Windows Server 2003 CD-ROM into the CD-ROM drive of your computer. If you hold down the Shift key as you do so, you can bypass the CD's autorun feature.
2. | Open My Computer, right-click the CD-ROM drive, and select Explore.
3. | Open the support\tools directory and double-click the deploy.cab file to open it.
4. | Select all the files that are in the right pane, right-click, and select Extract.
5. | Select the folder where you want to place the files (or make a new folder) and click Extract.
6. | Open the folder where you placed the files and double-click the Setupmgr.exe file.
7. | When the Setup Manager Wizard starts, follow the instructions to create your answer file.

Creating an Unattended Installation Script

To create an unattended answer file, open the folder where you placed the files you extracted. Double-click the Setupmgr.exe file and follow the instructions in the Setup Manager Wizard.

Sample unattend.txt File

The unattend.txt file can be extremely simple or extremely complex, ranging in size from a few dozen lines of code to a few hundred.

The following is a sample unattend.txt file that was created in about five minutes using the Setup Manager:

;SetupMgrTag
[Data]
AutoPartition=1
MsDosInitiated="0"
UnattendedInstall="Yes"

[Unattended]
    UnattendMode=FullUnattended

    OemSkipEula=Yes
    OemPreinstall=Yes
    TargetPath=\WINDOWS

[GuiUnattended]
    AdminPassword=xxxxxxxx
    EncryptedAdminPassword=Yes
    OEMSkipRegional=1
    TimeZone=4
    OemSkipWelcome=1

[UserData]
    ProductKey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
    FullName="Rand Morimoto"
    OrgName="Convergent Computing"
    ComputerName=WNS-Server-One

[Display]
    Xresolution=800
    YResolution=600

[LicenseFilePrintData]
    AutoMode=PerServer
    AutoUsers=10

[TapiLocation]
    CountryCode=1
    Dialing=Tone
    AreaCode=510

[SetupMgr]
    DistFolder=C:\windist
 installation
    DistShare=windist

[Components]
    accessopt=On
    calc=On
    charmap=On
    clipbook=On
    deskpaper=On
    templates=On
    mousepoint=On
    paint=On
    freecell=Off

    hearts=Off
    zonegames=Off
    minesweeper=Off
    solitaire=Off
    spider=Off
    indexsrv_system=On
    msnexplr=Off
    certsrv=Off
    certsrv_client=Off
    certsrv_server=Off
    iis_www=Off
    iis_ftp=Off
    iis_smtp=Off
    iis_smtp_docs=Off
    iis_nntp=Off
    iis_nntp_docs=Off
    reminst=Off
    rstorage=Off
    TerminalServer=On
    wms=Off
    wms_admin_asp=Off
    wms_admin_mmc=Off
    wms_server=Off
    chat=On
    dialer=On
    hypertrm=On
    cdplayer=On
    mplay=On
    media_clips=On
    media_utopia=On
    rec=On
    vol=On

[Identification]
    JoinDomain=companyabc
    DomainAdmin=companyabc\administrator
    DomainAdminPassword=password

[Networking]
    InstallDefaultComponents=No

[NetAdapters]
    Adapter1=params.Adapter1

[params.Adapter1]
    INFID=*

[NetClients]
    MS_MSClient=params.MS_MSClient

[NetServices]
    MS_SERVER=params.MS_SERVER

[NetProtocols]
    MS_TCPIP=params.MS_TCPIP

[params.MS_TCPIP]
    DNS=No
    UseDomainNameDevolution=No
    EnableLMHosts=Yes
    AdapterSections=params.MS_TCPIP.Adapter1

[params.MS_TCPIP.Adapter1]
    SpecificTo=Adapter1
    DHCP=No
    IPAddress=10.100.100.10
    SubnetMask=255.255.255.0
    DefaultGateway=10.100.100.1
    DNSServerSearchOrder=10.100.100.50,10.100.100.51
    WINS=Yes
    WinsServerList=10.100.100.60
    NetBIOSOptions=0

As you customize and begin using unattended script files, you will find that they can save you an enormous amount of time installing Windows Server 2003 on multiple systems.

Launching an Unattended Installation Script

When the Setup Manager creates the unattend.txt file, it will also create a batch file called unattend.bat. The batch file gives the name of the answer file (unattend.txt) and the location of the source files (\\WINSERVER\windist\I386). Next, the installation process is kicked off by the winnt32 command and the switches to call the files.

Note

Because the setup files (in this case) are located on a Windows server, you will need network connectivity before starting the batch file.

Sample unattend.bat File

The unattend.bat file is the batch file used to launch the unattended installation. The steps of the batch file can be executed manually; however, if the process is repeated several times, running a batch file like the following one will simplify the process:

@rem SetupMgrTag
@echo off
set AnswerFile=.\unattend.txt
set SetupFiles=\\WINSERVER\windist\I386
\\WINSERVER\windist\I386\winnt32 /s:%SetupFiles% /unattend:%AnswerFile%


Installing Windows Server 2003 from an Image

To deploy multiple servers that are configured the same way and that have similar hardware, you can't beat using an image-based installation. You can use Remote Installation Services (RIS) with the Remote Installation Preparation Wizard (RIPrep), the System Preparation tool (Sysprep) to prepare a server for imaging using Xcopy or third-party imaging software, or use the Feature Pack add-in Automated Deployment Services.

An image-based installation might be the answer for you if you have the following needs:

  • Installing identical operating systems, applications, and configurations on multiple servers

  • Performing clean installations (no upgrades)

Using Remote Installation Services

Using Remote Installation Services, better known as RIS, allows for a setup that is network initiated. When you combine this service with the Remote Installation Preparation Wizard (RIPrep), you can install a clean, imaged installation.

This method of installation, combined with PXE network cards, allows the setup program to be initiated with minimal user intervention. Boot floppy disks can also be used for certain PCI network interface cards that are not PXE compliant.

When using RIS, the client requests an IP address from a DHCP server. The client then contacts the RIS server, which in turn checks Active Directory to see whether the client has been prestaged. The RIS server either responds to the client or forwards the request to another RIS server. When the proper RIS server has been contacted, it sends Startrom.com to the client, which then launches OSChoice. OSChoice begins the remote installation service process.

Improvements to Remote Installation Services

With Windows Server 2003, Microsoft has enhanced RIS technology. RIS now has support for deploying all versions of Windows 2000, Windows XP Professional, and all 32-bit versions of the Windows Server 2003 family. And there is a significant performance improvement when compared to all previous versions.

Several security enhancements have been made as well. When a system is configured with RIS and is joined to the domain, the Domain Administrators group is added to the Local Administrators group; then the local administrator account is disabled. Also, as stated in the "Performing an Unattended Windows Server 2003 Installation" section, there is the ability to encrypt the administrator password.

Client Requirements for RIS

To use RIS to deploy a server, the computer must meet PXE 1.0 or 2.0 specifications. It must have a network interface card (NIC) that supports PXE or that is supported by the RIS boot floppy. Finally, the hardware must meet the minimum requirements for the version of Windows being installed.

Using the System Preparation Tool

In the past, one problem with imaging systems was that when the new (copied) system was brought online, there were conflicts with the old (original) system. The security identifier (SID), computer name, and IP address all were identical on the image and the original, and all of them are supposed to be unique on your network.

One way to resolve this problem is to use the System Preparation toolotherwise known as Sysprep. This tool prepares a system for imaging by removing certain configuration details, such as the SID, IP address, and computer name. The system is then imaged and, when the image is deployed, a mini-setup is run instead of the normal full setup. The user can answer just a few questions, and the installation is on its way.

To use Sysprep, you perform the installation once on the source computer, installing the operating system and any applications that you want deployed. After the source system is installed and configured, Sysprep is run on that system, which then powers off. Using an imaging tool, the system is then copied to a network location for distribution. A new system is booted using an imaging tool, connected to the network, and the image is copied from the network. When this new system is powered on, the mini-setup is run, and the installer is asked a few configuration questions. When the setup application is complete, the server can be turned off and is ready to distribute.

Improvements to the System Preparation Tool

Sysprep has been around for a while, and Microsoft has added some improvements that have made it easier to deploy imaged installations. One such enhancement, the factory switch, allows updated drivers to be picked up by the image before the system is fully set up. Also, you can now image products in the Windows Server 2003 family running IIS. And, as a time-saver, you no longer have to use the PnP switch to force Plug and Play enumeration on the next restart. In the past, this process added 5 to 10 minutes to the mini-setup.

Using the Automated Deployment Services Tool

For organizations looking to deploy identically configured Windows Server 2003 images to multiple servers, the Automated Deployment Services (ADS) tool simplifies the imaging task.

ADS uses the Preboot Execution Environment (PXE), which is similar to the Remote Installation Service (RIS), to deploy images to new servers. The significant benefit of ADS over RIS is the administrative tool that comes with ADS. The ADS administration tool provides administrators with a centralized view of stored images, the flexibility to automatically reconfigure images from a central location, and the ability to process images based on the needs of the organization.

ADS can be downloaded from the Microsoft Feature Pack Downloads page at http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx.


Installing Windows Server 2003 with Group Policy and Systems Management Server

As a final note, you can use Group Policy to upgrade Windows Server 2003 in the existing Active Directory or Systems Management Server (SMS) infrastructure. You can perform complete operating system upgrades or just install service packs.

You can also use SMS to inventory and confirm system compatibility before you upgrade and then to confirm that the upgrade to Windows Server 2003 was successful.

The combination of Group Policy and SMS can use a central installation point to perform upgrades on similar or dissimilar hardware. It can be used for the prestaging of servers as well, and is easy to reconfigure if your needs change.


Updating a Windows 2003 Server with a Service Pack

As with all Microsoft applications, Windows 2003 has periodic updates that become available for the software. Interim updates can be downloaded and installed via the Windows Update option on the system, or a visit to the Windows Update website (http://update.microsoft.com) will initiate the installer to check for the latest updates for Windows.

Major updates come in Service Packs that roll up patches and updates into a single installation. Installing a Service Pack brings a server up to date with all the updates to the point in time when the Service Pack was issued. The Service Packs for Windows 2003 are cumulative, so the installation of Service Pack 2 includes all the updates released prior to Service Pack 2, including the Service Pack 1 update.

There are three ways to install a Service Pack update:

  • Windows Update You can download and automatically install the Service Pack as part of the normal update process.

  • Download and Install You can download the Service Pack as a file and then launch it to install the update. Do this when your system is not connected to the Internet, or when you prefer to schedule an installation instead of performing an immediate installation after you've downloaded the file from the Internet.

  • Slipstream Installation For a new installation of Windows, you can merge the Service Pack into an existing copy of the Windows 2003 code, and then install the updated Windows 2003 code with Service Pack updates on your system.

Installing the Service Pack

The Windows Update method and the download and install method of updating a server with a Service Pack merely requires a copy of the Service Pack to be installed on an existing Windows 2003 server. The installation process will overwrite any old versions of drivers and files, and will update the system with the latest version that comes in the Service Pack.

If the Service Pack was downloaded, the file must be executed to install the files. The execution might be as follows:

WindowsServer2003-KB889101-SP1-x86-enu.exe

If the Service Pack is to be installed by the use of Windows Update to automatically install the Service Pack from the update screen, then choosing to "update" from the Windows Update screen will initiate the installation process of the Service Pack onto the system.

Slipstreaming the Service Pack into a New Installation Media

Like many other Microsoft products, Windows 2003 allows Service Packs to be merged into the original application code so that the installation can be a single process, instead of installing the original code and then applying the Service Pack. This merging of the service pack into the original code is called slipstreaming. Effectively, the updated code overwrites the original code and then is burned to a new CD that becomes the updated version of the installation software.

To prepare a slipstream copy of Windows 2003, do the following:

1.
Insert the Windows 2003 disc into the CD-ROM drive and copy the contents of the i386 directory into an empty directory on a hard drive.

2.
Extract the contents of the Service Pack into a different empty directory on the hard drive so that the files for the Service Pack are available. The following is an example of the command to extract the files:

WindowsServer2003-KB889101-SP1-x86-enu.exe /x

3.
Go into the update folder of the Service Pack directory and run the following command to slipstream the contents of the Service Pack into the original code directory (where c:\win2003\ is the location of the original Windows 2003 software, and c:\sp1\ is the directory of the Service Pack software):

c:\sp1\i386\update\update.exe s c:\win2003

The resulting files in the original Windows 2003 directory (c:\win2003 in this example) will be the original code updated with the Service Pack updates. This entire directory can now be burned back to a bootable CD-ROM as a CD that is now a Windows 2003 SP1 installation disc.


Preparing a System and Installing the Windows 2003 R2 Components

Windows 2003 R2 is a series of add-on components to Windows 2003 and is not a new operating system installation. The operating system off which Windows 2003 R2 runs is Windows 2003 SP1 or higher. If a system needs to be updated to support the Windows 2003 R2 components, a Service Pack version of Windows should be installed. If a system already has a Service Pack installed, the Windows 2003 R2 components can be installed right on the service packed system.

Preparing the Installation of Windows 2003 R2

There are three scenarios of configurations where Windows 2003 R2 would be installed. One scenario is where a system either already has Windows 2003 installed but without a Service Pack; another scenario is where a system has Windows 2003 with a Service Pack installed; and the third scenario is where a system is being installed from scratch with the Windows 2003 R2 CDs.

Preparing a System Without Service Packs

For a Windows 2003 system that does not have a Service Pack installed, the system will first need to be updated with the latest Service Pack. See the "Updating a Windows 2003 Server with a Service Pack" section, earlier in this chapter, for instructions on installing a Service Pack for Windows 2003. When the system has Service Pack 1 or higher installed, the Windows 2003 R2 components can be added to the system.

Preparing a System with a Service Pack

If a Windows 2003 server already has Service Pack 1 or higher installed, the Windows 2003 R2 components can be installed right on the system.

Preparing Windows 2003 R2 from Windows 2003 R2 Media

For a system being configured from the Windows 2003 R2 media, you will notice Windows 2003 R2 comes with two CDs. One CD is the core operating system, which is the Windows 2003 operating system that has a slipstream copy of the Service Pack on the media. When installing Windows from the Windows 2003 R2 CD-1, the Service Pack will automatically be installed at the time of installation.

After CD-1 has been installed, the Windows 2003 R2 CD-2 can be inserted and the Windows 2003 R2 update can be installed on the system.

Installing the Windows 2003 R2 Component Files

After the base configuration of a system has been installed that includes Windows 2003 with Service Pack 1 or higher, the Windows 2003 R2 components can be installed. Not all the Windows 2003 R2 components need to be installed on the system at the same time. In fact, it is better to install only the desired components; otherwise, a system will have unneeded components that can take up system CPU performance or will open up a security "surface area" that can be attacked by worms and viruses. By selectively installing only the necessary components for Windows 2003 R2, the organization can limit its security exposure and also keep a system configured to have only necessary components operating on the system.

To access the Windows 2003 R2 components, do the following:

1. | Insert the Windows 2003 R2 CD-2 disc into the disc drive.
2. | Autoplay will launch a installation window that will allow you to install the Windows 2003 R2 components. Choose Continue Windows 2003 R2 Setup.
3. | Depending on whether the server has a Service Pack installed, you might get a warning notifying you that you will not be able to uninstall the Windows 2003 R2 update once you proceed with the installation. Click Yes if you do not plan to downgrade the server of its Service Pack.
4. | From the Welcome screen of the Windows 2003 R2 component installer, choose Next to proceed.
5. | A Setup Summary screen will appear, notifying you that it will begin copying the Windows 2003 R2 components onto the system. Click Next to continue.
6. | After all the Windows 2003 R2 files have been copied, click Finished when prompted.

Note

Although the Windows 2003 R2 components will now be copied to the system, none of the R2 components will have been installed or activated on the server yet. The specific R2 components will need to be added and configured to make them work properly. See the next section, "Installing Specific Windows 2003 R2 Components."

Installing Specific Windows 2003 R2 Components

After the Windows 2003 R2 components have been copied onto the server, the server administrator can choose which Windows 2003 R2 components should be installed and enabled on the server. To install Windows 2003 R2 components, do the following:

1. | Determine which Windows 2003 R2 components you want to be enabled.
2. | From the desktop of the Windows 2003 server, click Start, Control Panel, Add/Remove Programs.
3. | Click the Add/Remove Windows Components option.
4. | Select the desired Windows components to add (those familiar with the normal list of Windows components to choose from will notice that new components now exist). After selecting the desired components to install, click Next to begin the installation process.
5. | After the Windows components have been installed on the system, click Finished when prompted.

Note

Although selective components have now been installed on the server, each component typically needs to be configured before the component works. See the next section, "Configuring the Individual Windows 2003 R2 Components," for more details.

Configuring the Individual Windows 2003 R2 Components

With the Windows 2003 R2 components installed and enabled on the server, each of the new components will typically need to be customized and configured. Sections throughout this book will cover the detailed component installation and configuration steps applicable to the component installed. The following chapters have more details on the configuration of individual Windows 2003 R2 components:

  • Active Directory Federation Services is covered in Chapter 8, "Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories."

  • Active Directory in Application Mode is covered in Chapter 8.

  • Network File System (NFS) is covered in Chapter 8.

  • Print Management Console (PMC) is covered in Chapter 19, "Windows Server 2003 Administration."

  • Distributed File System Replication (DFS) is covered in Chapter 30, "File System Fault Tolerance."

  • SharePoint Services is covered in Chapter 36, "Windows SharePoint Services."

  • File Server Resource Manager is covered in Chapter 19.

  • Subsystem for UNIX Applications/Identity Management for UNIX is covered in Chapter 8.


Summary

The Windows Server 2003 installation process and deployment tools bear similarities to those found in previous versions of Windows. However, feature and performance enhancements have improved the installation experiencewhether you are installing a single system by hand or deploying thousands of systems across your corporate environment.


Best Practices

  • Verify that your hardware is supported.

  • Stick to using the recommended or better hardware and software requirements.

  • Make sure you document your server configuration information and perform a backup of any data that you want to keep.

  • Test your applications for compatibility before migration.

  • Use a consistent naming convention to name the servers and client machines.

  • Use only Internet-standard characters in your computer name. This would include the letters AZ (upper- and lowercase), the numbers 09, and the hyphen (-).

  • Periodically verify that system backups can be used to recover a system in a lab environment.

  • Use the regular formatting option to perform a true format.

  • Use NTFS to create an efficient and secured filesystem.

  • If you are not sure which licensing mode to use for your environment, select Per Server.

  • Rename the Administrator account, for the sake of security, after you complete the installation.

  • Automate installation by using deployment tools such as RIS, Sysprep, RIPrep, Unattend files, and Group Policy (with SMS).

  • Choose and install Windows 2003 R2 components to a server to take advantage of new capabilities built in to Windows 2003.


Part II: Windows Server 2003 Active Directory

In This Part

CHAPTER 4 Active Directory Primer

CHAPTER 5 Designing a Windows Server 2003 Active Directory

CHAPTER 6 Designing Organizational Unit and Group Structure

CHAPTER 7 Active Directory Infrastructure

CHAPTER 8 Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories


Chapter 4. Active Directory Primer

In This Chapter

  • The Evolution of Directory Services

  • Understanding the Development of Active Directory

  • Active Directory's Structure

  • Active Directory's Components

  • Domain Trusts

  • Organizational Units

  • The Role of Groups in an Active Directory Environment

  • Active Directory Replication

  • The Role of DNS in Active Directory

  • Active Directory Security

  • Active Directory Changes in Windows Server 2003

The heart and soul of the Windows Server 2003 networking infrastructure resides in Active Directory, Microsoft's directory services implementation. Active Directory was devised to fill the directory services void in the Windows world and to serve as a platform for future integration of Microsoft technologies. A full understanding of the structure of Active Directory is vital to the understanding of the Windows Server 2003 environment as a whole.

In addition to the overall operating system enhancements, Windows Server 2003 expands upon the capabilities of Active Directory, adding the ability to rename domains, improving administrative tools, optimizing compression, and other long-awaited enhancements to the capabilities of the Active Directory environment. In addition, incremental improvements made to Windows Server 2003 have increased the functionality and flexibility of Active Directory, with tools such as Active Directory in Application Mode (ADAM).

This chapter describes an overview of directory services in general and specifically focuses on the overall development of Active Directory as an enterprise directory service. In addition, the basic components and functionality of Active Directory in Windows Server 2003 are summarized.


The Evolution of Directory Services

Directory services have existed in one form or another since the early days of computing to provide basic lookup and authentication functionality for enterprise network implementations. A directory service provides detailed information about a user or object in a network, much in the same way that a phonebook is used to look up a telephone number for a provided name. For example, a user object in a directory service can store the phone number, email address, department name, and as many other attributes as an administrator desires.

Directory services are commonly referred to as the white pages of a network. They provide user and object definition and administration. Early electronic directories were developed soon after the invention of the digital computer and were used for user authentication and to control access to resources. With the growth of the Internet and the increase in the use of computers for collaboration, the use of directories expanded to include basic contact information about users. Examples of early directories included MVS PROFS (IBM), Grapevine's Registration Database, and WHOIS.

Application-specific directory services soon arose to address the specific addressing and contact-lookup needs of each product. These directories were accessible only via proprietary access methods and were limited in scope. Applications utilizing these types of directories were programs such as Novell GroupWise Directory, Lotus Notes, and the Unix sendmail /etc/aliases file.

The further development of large-scale enterprise directory services was spearheaded by Novell with the release of Novell Directory Services (NDS) in the early 1990s. It was adopted by NetWare organizations and eventually was expanded to include support for mixed NetWare/NT environments. The flat, unwieldy structure of NT domains and the lack of synchronization and collaboration between the two environments led many organizations to adopt NDS as a directory service implementation. It was these specific deficiencies in NT that Microsoft addressed with the introduction of Active Directory.

The development of the Lightweight Directory Access Protocol (LDAP) corresponded with the growth of the Internet and a need for greater collaboration and standardization. This nonproprietary method of accessing and modifying directory information that fully utilized TCP/IP was determined to be robust and functional, and new directory services implementations were written to utilize this protocol. Active Directory itself was specifically designed to conform to the LDAP standard.

The Original Microsoft Directory Systems

Exchange 5.5 ran its own directory service as part of its email environment. In fact, Active Directory took many of its key design components from the original Exchange directory service. For example, the Active Directory database uses the same Jet database format as Exchange 5.5, the same types of utilities are necessary to run maintenance on the Active Directory database, and the site replication topology is similar in many ways.

Several other Microsoft applications ran their own directory services, namely Internet Information Server and Site Server. However, each directory service was separate from the others, and integration was not very tight between the different implementations.

Key Features of Active Directory

Five key components are central to Active Directory's functionality. As compatibility with Internet standards has become required for new directory services, the existing implementations have adjusted and focused on these areas:

  • TCP/IP compatibility Unlike some of the original proprietary protocols such as IPX/SPX and NetBEUI, the Transport Control Protocol/Internet Prococol (TCP/IP) was designed to be cross-platform. The subsequent adoption of TCP/IP as an Internet standard for computer communications has propelled it to the forefront of the protocol world and essentially made it a requirement for enterprise operating systems. Active Directory and Windows Server 2003 utilize the TCP/IP protocol stack as their primary method of communications.

  • Lightweight Directory Access Protocol support The Lightweight Directory Access Protocol (LDAP) has emerged as the standard Internet directory protocol and is used to update and query data within the directory. Active Directory directly supports LDAP.

  • Domain Name System (DNS) support DNS was created out of a need to translate simplified names that can be understood by humans (such as www.cco.com) into an IP address that is understood by a computer (such as 12.155.166.151). The Active Directory structure supports and effectively requires DNS to function properly.

  • Security support Internet standards-based security support is vital to the smooth functioning of an environment that is essentially connected to millions of computers around the world. Lack of strong security is an invitation to be hacked, and Windows Server 2003 and Active Directory have taken security to greater levels. Support for IP Security (IPSec), Kerberos, Certificate Authorities, and support for Secure Sockets Layer (SSL) encryption is built into Windows Server 2003 and Active Directory. In addition, the last few years have seen a recent major push at Microsoft to further secure all aspects of its software to prevent embarrassing security melt-downs such as those caused by viruses and worms.

  • Ease of administration Although often overlooked in powerful directory services implementations, the ease in which the environment is administered and configured directly affects the overall costs associated with its use. Active Directory and Windows Server 2003 are specifically designed for ease of use to lessen the learning curve associated with the use of a new environment. In addition, Windows Server 2003 includes numerous administrative improvements over Windows 2000, in the form of additional command-line tools for scripting, "headless" management capabilities, software restriction policies, and an enhanced GUI based on Windows XP.


Understanding the Development of Active Directory

Introduced with Windows 2000, Active Directory (commonly referred to as AD) has achieved wide industry recognition and acceptance and has proven itself in reliability, scalability, and performance. The introduction of AD served to address some limitations in the NT 4.0 domain structure design and also allowed for future Microsoft products to tie into a common interface.

The Limitations of NT 4.0 Domains

Windows NT 4.0 domains, while possessing enhanced security over previous Windows Workgroup models, have several functional shortcomings that have limited their use as enterprise directories. The Windows NT domain is basically a flat namespace that stores very little information about a user beyond the basic username, password, and so on. In addition, further organization of users beyond the domain level is essentially not possible.

In addition, a typical NT 4.0 domain has basically two types of users: full-blown administrators and standard users. In a nutshell, you were either a super administrator of the domain or just a simple network user. This kept delegation of administration simple but didn't provide for the type of granular security required by many larger organizations. These organizations needed administrative tasks to be subdivided and strictly defined, and Windows NT domains did not provide these capabilities. To get around this problem, many organizations set up multiple resource and user domains, dividing them by geographical location and/or political subdivision. The resulting special administrative issues could confuse even a seasoned NT guru. Often, one individual had several user accounts in multiple domains with multiple passwords. Needless to say, this drawback has been addressed in the granular administrative design within Active Directory.

Connectivity between NT 4.0 domains was accomplished through the manual setup of one- or two-way trusts between the domains. The domain trusts allowed for the domain controllers in the "trusting" domain to accept credentials that were validated by domain controllers in the "trusted" domain. The trusts were not transitive, however, which meant that if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A does not trust Domain C unless you specifically create a trust between Domain A and Domain C. The problem with this model was that multiple domain trusts between several domains started to look like a "spaghetti" domain structure similar to the trust configuration shown in Figure 4.1.

Figure 4.1. Spaghetti domain structure in Windows NT4.

This type of domain structure, as any NT 4.0 administrator can attest, becomes frustratingly difficult to administer and troubleshoot, as new administrators must determine what is meant by "trusted" and "trusting" domains and even veterans have a hard time visualizing their trust relationships from memory.

In addition to the complicated trust schemes, the Windows NT primary domain controller (PDC) is a single point of failure within an NT domain. If the PDC went down for whatever reason, it would severely affect domain functionality. Large organizations were likewise limited by the object limitations of NT 4.0 domains, which could not scale higher than 44,000 objects in any one domain.

These limitations were aggressively addressed with the development of Windows 2000 and Active Directory. Windows Server 2003 expands upon the functionality of Windows 2000 and takes the administrative capabilities of Active Directory even further.

Microsoft's Adoption of Internet Standards

Since the early development of Windows 2000, and subsequently Windows Server 2003, Microsoft has strived to make all its products embrace the Internet. Standards that before had been options or previously incompatible were subsequently woven into the software as primary methods of communication and operability. All applications and operating systems became TCP/IP compliant, and proprietary protocols such as NetBEUI were phased out. With the introduction of Windows Server 2003, the Internet readiness of the Microsoft environment reaches new levels of functionality.


Active Directory's Structure

The logical structure of Active Directory enables it to scale from small offices to large multinational organizations. Administrative granularity is built in to allow delegation of control to groups or specific users. No longer is the assigning of administrative rights an all or nothing scenario.

Active Directory loosely follows an X.500 directory model but takes on several characteristics of its own. Many of us are already getting used to the forests and trees of Active Directory, and some limitations that existed before in Windows 2000 have been lifted. To understand Active Directory, we must first take a good look at its core structural components.

The Active Directory Domain

An Active Directory (AD) domain is the main logical boundary of Active Directory. In a standalone sense, an AD domain looks very much like a Windows NT domain. Users and computers are all stored and managed from within the boundaries of the domain. However, several major changes have been made to the structure of the domain and how it relates to other domains within the Active Directory structure.

Domains in Active Directory serve as administrative security boundaries for objects and contain their own security policies. For example, different domains can contain different password policies for users. It is important to keep in mind that domains are a logical organization of objects, and can easily span multiple physical locations. Consequently, it is no longer necessary to set up multiple domains for different remote offices or sites as replication concerns are more properly addressed with the use of Active Directory sites, which will be described in greater detail in the following sections.

Note

One of the key differences between AD domains in Windows 2000 and AD domains in Windows Server 2003 is that administrators now have the ability to rename domains. For this to occur, however, all domain controllers within the forest must be converted to Windows Server 2003 domain controllers and the Active Directory forest functionality levels must be raised to support Windows Server 2003. In addition, if Exchange is a part of the forest, the Exchange organization must be brought to Exchange Server 2003 Service Pack 1 levels before renaming a domain. A detailed discussion of the Active Directory domain rename tools is provided in Chapter 5, "Designing a Windows Server 2003 Active Directory."

Active Directory Domain Trees

An Active Directory tree is composed of multiple domains connected by two-way transitive trusts. Each domain in an Active Directory tree shares a common schema and global catalog. In Figure 4.2, the root domain of the Active Directory tree is companyabc.com and the subdomains are asia.companyabc.com and europe.companyabc.com.

Figure 4.2. A simple Windows Server 2003 Active Directory tree with subdomains.

The transitive trust relationship is automatic, which is a change from the domain structure of NT 4.0, in which all trusts had to be set up manually. The transitive trust relationship means that because the Asia domain trusts the root companyabc domain, and the Europe domain trusts the companyabc domain, the Asia domain trusts the Europe domain as well. The trusts flow through the domain structure.

Note

Although trusts are transitive in a Windows Active Directory environment, that does not mean that permissions are fully accessible to all users or even to administrators between domains. The trust only provides a pathway from one domain to another. By default, no access rights are granted from one transitive domain to another. The administrator of a domain must issue rights for users or administrators in another domain to access resources within their domain.

All domains within a tree share the same namespace, in this example companyabc.com, but have security mechanisms in place to segregate access from other domains. In other words, an administrator in the Europe domain could have relative control over his entire domain, without users from the Asia or companyabc domains having privileges to resources. Conversely, the administrators in Europe can allow groups of users from other domains access if they so want. The administration is granular and configurable.

Caution

As will become evident in later sections of this chapter, the domain is not the ultimate security boundary in AD; specific exploits that take advantage of the transitive trusts between domains in a forest make the forest boundary the absolute security layer.

Forests in Active Directory

Forests are a group of interconnected domain trees. Implicit trusts connect the roots of each tree together into a common forest.

The overlying characteristics that tie together all domains and domain trees into a common forest are the existence of a common schema and a common global catalog. However, domains and domain trees in a forest do not need to share a common namespace. For example, the domains microsoft.com and msnbc.com could theoretically be part of the same forest but maintain their own separate namespaces (for obvious reasons).

Forests are the main organizational security boundary for Active Directory, and it is assumed that all administrators within a forest are trusted to some degree. If an administrator is not trusted, that administrator should be placed in a separate forest.

Note

Early on in the life of Active Directory, domains were considered to be its security boundary. Administrators within the forest did not necessarily have to trust each other and could be separated into domains. However, the January 2002 Microsoft Security Bulletin MS02-001 identified a vulnerabilty called the "Domain Trust Vulnerability." This vulnerability allows an administrator to use SIDHistory to elevate his privilege to any other domain in the forest. Although not easy to acomplish, it is still possible. SID filtering can be used between forests to prevent this attack, but not within forests. Thus, the security boundary for Active Directory was pushed from the domain to the forest.

Active Directory Authentication Modes

Windows NT 4.0 used a system of authentication known as NT LAN Manager (NTLM). This form of authentication sent the encrypted password across the network in the form of a hash. The problem with this method of authentication was that anyone could monitor the network for passing hashes, collect them, and then use third-party decryption tools, which effectively decrypt the password using dictionary and brute-force techniques.

Windows 2000 and Windows Server 2003 utilize a form of authentication known as Kerberos, which is described in greater detail in the following sections. In essence, Kerberos does not send password information over the network and is inherently more secure than NTLM. However, Kerberos authentication is not required by default in Active Directory because AD is set up by default to be backward compatible for legacy Windows clients.

Functional Levels in Windows Server 2003 Active Directory

Just as Windows 2000 is installed to be initially compatible with legacy Windows NT domains and clients, Windows Server 2003 initially does not upgrade the Active Directory forest to Windows Server 2003 functionality. This helps to maintain backward compatibility with Windows 2000 and Windows NT4 domain controllers. Four separate functional levels exist at the domain level in Windows Server 2003, and three separate functional levels exist at the forest level.

  • Windows 2000 Mixed Domain Functional Level When Windows Server 2003 is installed into a Windows 2000 Active Directory forest that is running in Mixed mode, it essentially means that Windows Server 2003 domain controllers will be able to communicate with Windows NT and Windows 2000 domain controllers throughout the forest. This is the most limiting of the functional levels, however, because functionality such as universal groups, group nesting, and enhanced security is absent from the domain. This is typically a temporary level to run in because it is seen more as a path toward eventual upgrade.

  • Windows 2000 Native Functional Level Installed into a Windows 2000 Active Directory that is running in Windows 2000 Native mode, Windows Server 2003 will run itself at a Windows 2000 functional level. Only Windows 2000 and Windows Server 2003 domain controllers can exist in this environment.

  • Windows Server 2003 Interim Functional Level Windows Server 2003 Interim mode enables Windows Server 2003 Active Directory to interoperate with a domain composed of Windows NT 4.0 domain controllers only. Although a confusing concept at first mention, the Windows Server 2003 Interim functional level does serve a purpose. In environments that seek to upgrade directly from NT 4.0 to Windows Server 2003 Active Directory, Interim mode allows Windows Server 2003 to manage large groups more efficiently than if an existing Windows 2000 Active Directory exists. After all NT domain controllers have been removed or upgraded, the functional levels can be raised.

  • Windows Server 2003 Functional Level The most functional of all the various levels, Windows Server 2003 functionality is the eventual goal of all Windows Server 2003 Active Directory implementations. Functionality on this level opens the environment up to features such as schema deactivation, domain rename, domain controller rename, and cross-forest trusts. To get to this level, first all domain controllers must be updated to Windows Server 2003. Only after this can the domains and then the forest be updated to Windows Server 2003 functionality.

To bring a Windows Server 2003 forest to Windows Server 2003 functional levels, perform the following steps:

1.
Ensure that all domain controllers in the forest are upgraded to Windows Server 2003.

2.
Open Active Directory Domains and Trusts from the Administrative Tools menu.

3.
In the left scope pane, right-click on the domain name and then click Raise Domain Functional Level.

4.
In the box labeled Raise Domain Functional Level, shown in Figure 4.3, select Windows Server 2003 and then click Raise.

Figure 4.3. Raising the functional level of the Windows Server 2003 domain.

5.
Click OK and then click OK again to complete the task.

6.
Repeat steps 15 for all domains in the forest.

7.
Perform the same steps on the forest root, except this time choose Raise Forest Functional Level and follow the prompts.

When all domains and the forest level have been raised to Windows Server 2003 functionality, various Windows Server 2003 activities such as domain rename can be accomplished, and full realization of the Windows Server 2003 Active Directory capabilities can be achieved. Remember, before you accomplish this task, Windows Server 2003 will essentially be operating in a Mixed mode of compatibility, much as Windows 2000 initially ran in a Mixed mode with Windows NT Servers.


Active Directory's Components

The main components of Active Directory were designed to be highly configurable and secure. Active Directory and all it contains are physically located in a database file but are composed of a wide assortment of objects and their attributes. Many of these characteristics are familiar to those acquainted with other directory services products, but there are some new additions as well.

Understanding Active Directory's X.500 Roots

Active Directory loosely follows, but does not exactly conform to, the X.500 directory services information model. In a nutshell, X.500 defines a directory service through a distributed approach defined by a Directory Information Tree (DIT). This logically divides a directory service structure into the now familiar servername.subdomainname.domainname.com layout. In X.500, directory information is stored across the hierarchical layout in what are called Directory System Agents (DSAs). Microsoft designed Active Directory around many of the basic principles of the X.500 definition, but AD itself is not compatible with X.500 implementations, as X.500 follows an OSI model that is inefficient under the TCP/IP implementation that Active Directory follows.

The AD Schema

The Active Directory schema is a set of definitions for all object types in the directory and their related attributes. The schema determines the way that all user, computer, and other object data are stored in AD and configured to be standard across the entire Active Directory structure. Secured by the use of Discretionary Access Control Lists (DACLs), the schema controls the possible attributes to each object within Active Directory. In a nutshell, the schema is the basic definition of the directory itself and is central to the functionality of a domain environment. Care should be taken to delegate schema control to a highly selective group of administrators because schema modification affects the entire AD environment.

Schema Objects

Objects within the Active Directory structure such as Users, Printers, Computers, and Sites are defined in the schema as objects. Each object has a list of attributes that define it and that can be used to search for that object. For example, a User object for the employee named Weyland Wong will have a FirstName attribute of Weyland and a LastName attribute of Wong. In addition, there may be other attributes assigned, such as departmental name, email address, and an entire range of possibilities. Users looking up information in Active Directory can make queries based on this information, for example, searching for all users in the Sales department.

Extending the Schema

One of the major advantages to the Active Directory structure is the ability to directly modify and extend the schema to provide for custom attributes. A common attribute extension occurs with the installation of Microsoft Exchange Server, which extends the schema, more than doubling it in size. An upgrade from Windows 2000 Active Directory to Windows Server 2003 Active Directory also extends the schema to include attributes specific to Windows Server 2003. Many third-party products have their own schema extensions as well, each providing for different types of directory information to be displayed.

Performing Schema Modifications Using the ADSIEdit Tool

An interesting method of actually viewing the nuts and bolts of the Active Directory schema is by using the Active Directory Service Interfaces (ADSIEdit) utility. This utility was developed to simplify access to the Active Directory and can also view any compatible foreign LDAP directory. The ADSI utility, shown in Figure 4.4, enables an administrator to view, delete, and modify schema attributes. Great care should be taken before schema modifications are undertaken because problems in the schema can be difficult to fix.

Figure 4.4. Viewing and editing the Active Directory schema using the ADSI edit utility.

[View full size image]

Lightweight Directory Access Protocol

The Directory Service Protocol that is utilized by Active Directory is based on the Internet-standard Lightweight Directory Access Protocol (LDAP) defined by RFC-1777. LDAP allows queries and updates to take place in Active Directory. Objects in an LDAP-compliant directory must be uniquely identified by a naming path to the object. These naming paths take two forms: distinguished names and relative distinguished names.

Distinguished Names in AD

The distinguished name of an object in Active Directory is represented by the entire naming path that the object occupies in Active Directory. For example, the user named Kathi Honnegger can be represented by the following distinguished name:

CN=Kathi Honnegger,OU=Marketing,DC=COMPANYABC,DC=COM

The CN component of the distinguished name is the common name, which defines an object within the directory. The OU portion is the organizational unit in which the object belongs. The DC components define the DNS name of the Active Directory domain.

Relative Distinguished Names

The relative distinguished name of an object is basically a truncated distinguished name that defines the object's place within a set container. For example, take a look at the following object:

OU=Marketing,DC=COMPANYABC,DC=COM

This object would have a relative distinguished name of OU=Marketing. The relative distinguished name in this case defines itself as an organizational unit within its current domain container.

Multi-Master Replication with AD Domain Controllers

As in NT 4.0, Active Directory uses domain controllers (DCs) to authenticate users. However, the primary domain controllers and backup domain controllers (BDCs) have been replaced with the concept of multiple domain controllers that each contain a master read/write copy of domain information. Changes that are made on any domain controller within the environment are replicated to all other domain controllers in what is known as multi-master replication.

Global Catalog and Global Catalog Servers

The global catalog is an index of the Active Directory database that contains a partial copy of its contents. All objects within the AD tree are referenced within the global catalog, which allows users to search for objects located in other domains. Not every attribute of each object is replicated to the global catalogs, only those attributes that are commonly used in search operations, such as first name, last name, and so on.

Global catalog servers, commonly referred to as GCs or GC/DCs, are Active Directory domain controllers that contain a copy of the global catalog. It is wise to either locate a minimum of one global catalog server in each physical location or utilize Global Catalog Caching in remote sites as the global catalog must be referenced often by clients and the traffic across slower WAN links would limit this traffic. In addition, technologies such as Microsoft Exchange Server need fast access to global catalog servers for all user transactions, making it very important to have a global catalog server nearby.

Often, a larger organization will employ the use of multiple domain controllers and multiple global catalog servers in each large location, which distributes load, provides redundancy, and locates resources where they are needed. Choosing the right blend of global catalog servers and domain controllers is vital to the proper functionality of your Active Directory environment.

Operations Master (OM) Roles

Most domain controller functionality in Windows 2000 and Windows Server 2003 was designed to be distributed, multi-master-based. This effectively eliminated the single point of failure that was present with Windows NT PDCs. However, five functions still require the use of a single server because their functionality makes it impossible to follow a distributed approach. These Operations Master (OM, also known as Flexible Single Master Operations, or FSMO) roles are outlined as follows:

  • Schema master There is only one writable master copy of the AD schema in a single AD forest. It was deliberately designed this way to limit access to the schema and to minimize potential replication conflicts. There can be only one schema master in the entire Active Directory forest.

  • Domain naming master The domain naming master is responsible for the addition of domains into the Active Directory forest. This OM role must be placed on a global catalog server because it must have a record of all domains and objects to perform its function. There can be only one domain naming master in a forest.

  • PDC Emulator The PDC Emulator does exactly what its name implies: It handles down-level clients by performing functionality previously handled by the NT primary domain controller. This functionality is not necessary when operating in Windows 2000or Windows Server 2003only modes (native modes). It is important to note that if the server running the PDC Emulator goes down, any down-level clients will have trouble with domain functions (just as though an NT PDC went down). There is one PDC Emulator FSMO role per Active Directory domain.

  • RID master All objects within Active Directory that can be assigned permissions are uniquely identified through the use of a Security ID (SID). Each SID is composed of a domain SID, which is the same for each object in a single domain, and a Relative ID (RID), which is unique for each object within that domain. When assigning SIDs, a domain controller must be able to assign a corresponding RID from a pool that it obtains from the RID master. When that pool is exhausted, it requests another pool from the RID master. If the RID master is down, you may not be able to create new objects in your domain if a specific domain controller runs out of its allocated pool of RIDs. There is one RID master per Active Directory domain.

  • Infrastructure master The infrastructure master manages references to domain objects not within its own domain. In other words, a DC in one domain contains a list of all objects within its own domain, plus a list of references to other objects in other domains in the forest. If a referenced object changes, the infrastructure master handles this change. Because it deals with only referenced objects and not copies of the object itself, the infrastructure master must not reside on a global catalog server in multiple domain environments. The only exceptions to this are if every domain controller in your domain is a global catalog server or if you are in a single-domain environment. In the first case, there is no need to reference objects in other domains because full copies are available. In the second case, the infrastructure master role is not utilized because all copies of objects are local to the domain.

Transfer of an OM role to another domain controller, whether in a disaster recovery situation or simply for design purposes, is accomplished through two methods. The first involves using the Change Schema Master function of the Active Directory schema snap-in. In disaster recovery situations in which the schema master, domain naming master, or RID master has gone down and no backup is available, however, the OM roles can be seized through the use of a command-line tool called ntdsutil, shown in Figure 4.5. Keep in mind that you should use this utility only in emergency situations and should never bring the old OM server back online into the domain at risk of some serious system conflicts. Domain maintenance and recovery are covered in Chapters 22, "Windows Server 2003 Management and Maintenance Practices," and 33, "Recovering from a Disaster."

Figure 4.5. Viewing the ntdsutil utility for Active Directory management.

[View full size image]


Domain Trusts

The trust structure that was developed in Windows 2000 and is subsequently used in Windows Server 2003 has been streamlined in comparison to the Windows NT trust structure. Windows NT trusts utilized individual, explicitly defined trusts for each organizational domain. This created an exponential trust relationship, which was difficult, to say the least, to manage. Windows 2000 took the trust relationship to a new level of functionality, with transitive trusts supplying automatic paths "up and down the tree." These trusts are implicitly easier to understand and troubleshoot, and have greatly improved the manageability of Windows networks. In addition, Windows Server 2003 provides for additional functionality, such as cross-forest transitive trusts, which expands the capabilities of the NOS even further.

Transitive Trusts

Two-way transitive trusts are automatically established upon the creation of a subdomain or with the addition of a domain tree into an Active Directory forest. Transitive trusts are normally two way, with each domain trusting the other domain. In other words, users in each domain can access resources such as printers or servers in the other domain if they are explicitly given rights in those domains. Bear in mind that just because two domains have a trust relationship does not mean that users from one domain can automatically access all the resources in the other domain; it is simply the first step in accessing those resources. The proper permissions still need to be applied.

Explicit Trusts

Explicit trusts are those that are set up manually, similar to the way that Windows NT trusts were constructed. A trust may be set up to join two unrelated domain trees into the same forest, for example. Explicit trusts are one way, but two explicit trusts can be established to create a two-way trust. In Figure 4.6, an explicit trust has been established between the companyabc domain and the companyxyz domain to allow them to share cross-forest resources.

Figure 4.6. Sample explicit trust between two domain trees.

[View full size image]

When an explicit trust is set up to expedite the flow of trusts from one subdomain to another, it is known as a shortcut trust. Shortcut trusts simply allow authentication verifications to be processed faster, as opposed to having to move up and down a domain tree. In Figure 4.7, while a transitive trust exists between the asia.companyabc.com and the europe.companyabc.com domains, a shortcut trust has been created to minimize authentication time for access between the two subdomains of this organization.

Figure 4.7. A sample shortcut trust between two subdomains in a forest.

Another possible use for explicit trusts is to allow connectivity between an Active Directory forest and an external domain. These types of explicitly defined trusts are known as external trusts, and they allow different forests to share information without actually merging schema information or global catalogs.

Note

The capability to establish cross-forest trusts in Windows 2000 was limited to explicit trusts that were defined between each domain that needed access to a forest. Windows Server 2003 adds the capability to establish cross-forest transitive trusts, where the trust relationships flow through separate forests. This concept is explained in more detail in Chapter 5, "Designing a Windows Server 2003 Active Directory."


Organizational Units

As defined in the RFC for the LDAP standard, organizational units (OUs) are containers that logically store directory information and provide a method of addressing Active Directory through LDAP. In Active Directory, OUs are the primary method for organizing user, computer, and other object information into a more easily understandable layout. As shown in Figure 4.8, the organization has a root organizational unit where three nested organizational units (marketing, IT, and research) have been placed. This nesting enables the organization to distribute users across multiple containers for easier viewing and administration of network resources.

Figure 4.8. Viewing an organizational unit structure that provides a graphical view of network resource distribution.

As you can see, OUs can be further subdivided into resource OUs for easy organization and delegation of administration. Far-flung offices could have their own OUs for local administration as well. It is important to understand, however, that an OU should be created typically when the organization has a specific need to delegate administration to another set of administrators. If the same person or group of people administer the entire domain, there is no need to increase the complexity of the environment by adding OUs. In fact, too many OUs can affect group policies, logons, and other factors. Chapter 6, "Designing Organizational Unit and Group Structure," gives a detailed rundown of the design considerations encountered with organizational units.

Determining Domain Usage Versus OU Usage

As previously mentioned, some administrators tend to start applying the Active Directory domain structure to political boundaries within the organization. The dry-erase markers come out and very soon well-meaning managers get involved, organizing the Active Directory structure based on political boundaries. Subdomains start to become multiple layers deep, with each department taking its own subdomain. The problem with this strategy is that the Active Directory structure allows for this type of administrative granularity without division into multiple domains. In fact, the rule of thumb when designing domains is to start with a single domain and add additional domains only when necessary. In a nutshell, the type of administrative control required by many organizations can be realized by division of groups into separate organizational units rather than into separate domains.

OUs can therefore be structured to allow for separate departments to have various levels of administrative control over their own users. For example, a secretary in the Engineering department can be delegated control of resetting passwords for users within his own OU. Another advantage of OU use in these situations is that users can be easily dragged and dropped from one OU to another. For example, if users are moved from one department to another, moving them into their new department's OU is extremely simple.

It is important to keep in mind that OU structure can be modified on the fly any time an administrator feels fit to make structural changes. This gives Active Directory the added advantage of being forgiving for OU design flaws because changes can be made at any time.


The Role of Groups in an Active Directory Environment

The AD group structure, although not new in Active Directory, provides an efficient mechanism for managing security on large numbers of users. Without groups to logically organize users, permissions on each object in a network would have to be set up manually on a per-user basis. This means that if an entire department needed access to a printer, each user would need to be manually entered into the permissions list of that printer. These tasks would make the administration of security daunting.

The concept of groups was therefore devised to ease administration. If a large department needed access to that same printer, the department's group need only be supplied the necessary permissions. This greatly eases security-based administration and has the added advantage of providing for ease of transition if specific users leave the company or are transferred to a different department. For example, imagine an administrator in charge of printing and her user account is a member of a group named Printer Admins, which has full administrative privilege to the printers. Now, if this user transfers to become an email administrator, for example, reassigning permissions to a new print administrator is as simple as adding that new user to the Printer Admins group. This capability greatly simplifies these types of situations.

Groups in Active Directory work in the way that previous group structures, particularly in Windows NT, have worked, but with a few modifications to their design. Groups are divided into two categories: group type and group scope. There are two group types in Active Directory: security and distribution. Essentially, a security group can be used to apply permissions to objects for the members of the group. A distribution group, on the other hand, cannot be used for permissions but is used instead to send mail to members of the group. Group scope in Active Directory is likewise divided into several components, defined as follows:

  • Machine local groups Machine local groups, also known as simply "local groups," previously existed in Windows NT 4.0 and can theoretically contain members from any trusted location. Users and groups in the local domain, as well as in other trusted domains and forests, can be included in this type of group. However, it is important to note that local groups allow resources to be accessed only on the machine where they are located, which greatly reduces their usability.

  • Domain local groups Domain local groups are essentially the same thing as local groups in Windows NT, and are used to administer resources located only on their own domain. They can contain users and groups from any other trusted domain but are available only in native Windows 2000 domains. Most typically, these types of groups are used to grant access to resources for groups in different domains.

  • Global groups Global groups are on the opposite side from domain local groups. They can contain users only in the domain in which they exist but are used to grant access to resources in other trusted domains. These types of groups are best used to supply security membership to user accounts that share a similar function, such as the sales global group.

  • Universal groups Universal groups can contain users and groups from any domain in the forest and can grant access to any resource in the forest. Along with this added power come a few caveats. First, universal groups are available only in Native mode domains. Second, all members of each universal group are stored in the global catalog, increasing the replication load. It is important to note, however, that universal group membership replication has been noticeably streamlined and optimized in Windows Server 2003 because the membership is incrementally replicated.

Types of Groups

Although groups are covered in more detail in Chapter 6, the type of group used (domain local, global, or universal) has significant impact on replication of group objects for large multidomain organizations as well as organizations with sites connected through slow links.

For a single domain organization with high-speed connections to all sites, domain local, global, and universal groups are effectively the same because the organization has only one domain, and replication occurs at high speeds to all domain controllers.

However, in a multidomain environment, by default, only the group name of a global group replicates between domains, not the membership names. Therefore, if a user in one domain wants to view the member list of a global group in another domain, the user's request will have to query across a WAN to the other domain to view the membership of the global group.

Universal groups, on the other hand, do replicate group membership information between domains, so a user query of a universal group membership list will be immediately available in the user's local domain. However, because universal group membership replicates between domains, if a list of group members is not needed to replicate between domains, traffic can be minimized by simply making the group a global group.

Choosing Between OUs and Groups

Whereas OUs are primarily used to segregate administrative function, groups are useful for logical organization of security functions. Translated, OUs are created if there is a need for a department or physical location to have some certain type of administrative control over its own environment. For example, an organization with offices in Japan could organize its Japanese users into a separate OU and give a local administrator password-change and account-creation privileges for that OU. Groups, however, can be used to organize users to more easily apply security permissions. For example, you can create a group named Japanese Office Users that contains all the users from the office in Japan. Security permissions can then be established on objects in Active Directory using that group. They could, for example, be given privileges to folders in the main corporate location, something that could not be done at the OU level.

To summarize, the basic differences between OUs and groups is that groups can be used when applying security to objects, whereas OUs exist when certain administrative functionality needs to be delegated. Chapter 6 gives a more thorough explanation of groups and OU design.


Active Directory Replication

Replication in Active Directory is a critical function that is necessary to fulfill the functionality of a multimaster environment. The ability to make changes on any domain controller in a forest and then have those changes replicate to the other domain controllers is key. Consequently, a robust method of distributing this information was a major consideration for the development team at Microsoft. Active Directory replication is independent of the forest, tree, or domain structure, and it is this flexibility that is central to AD's success.

Sites, Site Links, and Site Link Bridgeheads

For purposes of replication, Active Directory logically organizes groups of servers into a concept known as sites. Typically speaking, a single site should be composed of servers that are connected to each other via high-speed connections. The links that are established to connect two or more locations connected potentially through slower-speed connections are known as site links. Sites are created with site links connecting the locations together to enable the administrator to specify the bandwidth used to replicate information between sites.

Rather than having information replicated immediately between servers within a high-speed connected site, the administrator can specify to replicate information between two sites only once per night or at a time when network demands are low, allowing more bandwidth availability to replicate Active Directory information.

Servers that funnel intersite replication through themselves are known as site link bridgeheads. Figure 4.9 shows a potential Windows Server 2003 Active Directory site structure. Site links exist between offices, and a domain controller in each site acts as the site link bridgehead. The site structure is completely modifiable, and should roughly follow the WAN structure of an organization. By default, only a single site is created in Active Directory, and administrators must manually create additional sites to be able to optimize replication. More on these concepts can be found in Chapter 7, "Active Directory Infrastructure."

Figure 4.9. Sample site structure where locations are connected by site links.

Originating Writes

Replication of objects between domain controllers is accomplished through the use of a property known as Originating Write. As changes are made to an object, this property is incrementally increased in value. A domain controller compares its own version of this value to the one received during a replication request. If it is lower, the change is applied; if not, it is discarded. This simplistic approach to replication is also extremely reliable and efficient and allows for effective object synchronization. For more information on replication, including a detailed analysis of Originating Writes and its other key components, refer to Chapter 7.


The Role of DNS in Active Directory

When Microsoft began development on Active Directory, full compatibility with the domain name system (DNS) was a critical priority. Active Directory was built from the ground up not just to be fully compatible with DNS but to be so integrated with it that one cannot exist without the other. Microsoft's direction in this case did not just happen by chance, but because of the central role that DNS plays in Internet name resolution and Microsoft's desire to make its product lines embrace the Internet.

While fully conforming to the standards established for DNS, Active Directory can expand upon the standard feature set of DNS and offer some new capabilities such as AD-Integrated DNS, which greatly eases the administration required for DNS environments. In addition, Active Directory can easily adapt to exist in a foreign DNS environment, such as Unix BIND, as long as the BIND version is 8.2.x or higher.

Given the importance of DNS in Windows Server 2003's Active Directory, a thorough understanding of DNS is a must. Chapter 9, "The Domain Name System," goes into greater detail on DNS in Windows Server 2003.

DNS Namespace Concepts

A DNS namespace, simply defined, is the bounded logical area formed by a DNS name and its subdomains. For example, europe.companyabc.com, asia.companyabc.com, and companyabc.com are all part of the same contiguous DNS namespace. A DNS namespace in Active Directory can be published on the Internet, such as microsoft.com or msn.com, or it can be hidden from public exposure, depending on the strategy and security needs of its implementers.

  • External (Published) Namespaces A DNS name that can be resolved from anywhere on the Internet is known as a published or external namespace. This type of namespace is common for organizations that want the full convenience of having their commonly used Internet domain name represent their Active Directory structure. While security becomes a larger issue for published Active Directory namespaces, the convenience of being able to access servers directly from the Internet makes this option a popular one for organizations. For example, an Exchange server running Outlook Web Access could be set up as mail. companyname.com and easily accessible from anywhere in the world. Users would more readily understand how to connect, and in these cases their email addresses would likely be name@companyname.com. This will not be the first time that the balancing act between greater security and convenience will arise during the design of a Windows Server 2003 deployment.

  • Internal (Hidden) Namespaces For many organizations, publication of their internal domain structure is too high a security risk, despite the advantages. These organizations can easily define their Active Directory with an internal namespace that is not readable from the Internet. For example, a company may have an external DNS namespace of cco.com but decide that its Active Directory structure will correspond to cco.internal or any namespace it wants. Bear in mind that any combination will work for internal namespaces because there is no limitation on using .com, .net, .gov, and so on when dealing with a namespace that is not published. For all intents and purposes, you could name your domain cucamonga.funkychicken if you want. For practical reasons, however, the .internal namespace has been specifically reserved for private name addressing, and using it is a best-practice approach in many cases.

Note

If you decide to use a domain namespace that theoretically could be bought and used on the Internet either now or in the future, it is wise to purchase the rights to that domain name to prevent potential conflicts with name resolution in the future. For example, if you choose the internal namespace companyabc.com, you may want to first verify that it is not taken and buy it if possible. If you find the domain name is already owned by another company, you may choose a different domain name for your Active Directory namespace. Even though your domain might not be published on the Internet, home or laptop users who need dial-in or VPN access to your domain may experience conflicts because they would be incorrectly routed to the wrong DNS name on the Internet instead of your company's namespace.

Dynamic DNS

Dynamic DNS (DDNS) was developed as an answer to the problem of DNS tables having to be manually updated when changes were made. DDNS in Windows Server 2003 automatically updates the DNS table based on registrations, and can work in conjunction with DHCP to automatically process DNS changes as clients are added and removed from the network infrastructure. DDNS is not required for Active Directory to function properly, but it makes administration much easier than previous manual methods.

Note

Although DDNS is fully supported by Windows Server 2003 and is typically enabled for all Windows Active Directory domain-to-domain name replication, DDNS is still sometimes not implemented at the enterprise level. Organizations with Unix-based DNS servers tend to manually or statically update DNS tables rather than dynamically update DNS tables. This is solely the choice of the DNS administrator in an organization to enable DDNS from Active Directory DNS to the enterprise DNS.

Comparing Standard DNS Zones and AD-Integrated DNS Zones

Standard DNS essentially stores all name records in a text file and keeps it updated via dynamic updates. If you are accustomed to using Unix BIND DNS or other standard forms of DNS, this is essentially what Standard DNS is in Windows Server 2003.

Active Directory expands upon other implementations of DNS by allowing administrators to integrate DNS into Active Directory. By doing this, the DNS zones themselves exist as objects in the Active Directory, which allows for automatic zone transfers to be accomplished. DNS replication traffic piggybacks off Active Directory traffic, and the DNS records are stored as objects in the directory. In Windows Server 2003's implementation of Active Directory, AD-integrated DNS zones are optimized by being stored in the application partition, thus reducing replication traffic and improving performance. For more information on DNS, see Chapter 9.

Understanding How AD DNS Works with Foreign DNS

Often, some local administrators may be hesitant to deploy Active Directory because of their desire to maintain their own foreign DNS implementation, usually Unix BIND. If this is the case, it is possible for Windows Server 2003 DNS to co-exist in this type of environment, as long as the DNS supports dynamic updates and SRV records (BIND 8.2.x or higher). These situations occur more often than not, as political situations within IT departments are often divided into pro-Microsoft and pro-Unix groups, each of which has its own ideology and plans. The ability of Windows Server 2003 to co-exist peacefully in these types of environments is therefore key. For a more detailed analysis of DNS in Windows Server 2003, see Chapter 9.


Active Directory Security

The security built around Active Directory and Windows Server 2003 was designed to protect valuable network assets and address many of the common security problems inherent in Windows NT 4.0. Windows Server 2003 expands on these security capabilities and was specifically designed to address issues such as the problems in Internet Information Server (IIS) that were exploited by viruses such as Code Red and Nimbda.

Development of Windows Server 2003 security has also been affected by the Trustworthy Computing initiative by Microsoft, which changed the primary focus of Microsoft products to security. In a nutshell, Microsoft is more focused than ever before on the security of its products, and all new features must pass a security litmus test before they can be released. This initiative has affected the development of Windows Server 2003 and is evident in the security features.

Kerberos Authentication

Kerberos was originally designed at M.I.T. as a secure method of authenticating users without actually sending a user password across the network, encrypted or not. Being able to send a password this way greatly reduces the threat of password theft because malicious users are no longer able to seize a copy of the password as it crosses the network and run brute-force attacks on the information to decrypt it.

The actual functionality of Kerberos is complicated, but essentially what happens is the computer sends an information packet to the client that requires authentication. This packet contains a "riddle" of sorts that can be answered only by the user's proper credentials. The user applies the "answer" to the riddle and sends it back to the server. If the proper password was applied to the answer, the user is authenticated. Although used in Windows Server 2003, this form of authentication is not proprietary to Microsoft, and is available as an Internet standard. For a greater understanding of Kerberos security, see Chapter 12, "Server-Level Security."

Understanding Why Internet Information Server v6 Is Disabled by Default

One of the chief criticisms of Microsoft's Internet Information Server and Microsoft products in general, for that matter, is a lack of security built into the products, both right out of the box and during standard operations. Components of IIS, especially Index Server, have proven to be vulnerable to virus and hack techniques such as those demonstrated by the infamous Code Red and Nimbda viruses. For these reasons, Microsoft disabled the Internet Information Server component in Windows Server 2003 by default. In addition, even when it is turned on, certain risky HTML verbs and other types of commonly used IIS exploit commands are disabled.

Taking Additional Security Precautions

Active Directory implementations are, in essence, as secure as the Windows Server 2003 environment in which they run. The security of the Active Directory structure can be increased through the utilization of additional security precautions, such as secured server-to-server communications using IPSec or the use of smart cards or other encryption techniques. In addition, the user environment can be secured through the use of group policies that can set parameter changes such as user password restrictions, domain security, and logon access privileges.


Active Directory Changes in Windows Server 2003

Improvements in the functionality and reliability of Active Directory are of key importance to the development team at Microsoft. It is therefore no small surprise that Windows Server 2003 introduces improvements in Active Directory. From the ability to rename Active Directory domains to improvements in replication compression, the changes made to the structure of Active Directory warrant a closer look.

  • Windows Server 2003 Active Directory Domain Rename Tool A promised feature of Active Directory that has been eagerly awaited is the ability to prune, splice, and rename Active Directory domains. Given the nature of corporate America, with restructuring, acquisitions, and name changes occurring constantly, the ability of Active Directory to be flexible in naming and structure is of utmost importance. The Active Directory rename tool was devised to address this very need.

    Before Active Directory domains can be renamed, several key prerequisites must be in place before the domain structure can be modified. First, and probably the most important, all domain controllers in the entire forest must be upgraded to Windows Server 2003 in advance. In addition, the domains and the forest must be upgraded to Windows Server 2003-functional level. Finally, comprehensive backups of the environment should be performed before undertaking the rename.

    The domain rename process is complex and should never be considered as routine. After the process, each domain controller must be rebooted and each member computer across the entire forest must also be rebooted (twice). For a greater understanding of the domain rename tool and process, see Chapter 5.

  • Improvements in the Configure Your Server Wizard The Configure Your Server (CYS) Wizard, introduced with Windows 2000 Server, has been vastly improved. If you were used to disabling this wizard in Windows 2000, you may think again in Windows Server 2003 because the wizard can be very helpful in configuring your server for the role that it will play, shutting off services that are not necessary and configuring ones that are needed. There are now options to configure a server as a Terminal server, as well as Routing and Remote Access Server (RRAS) configurations.

  • Cross-Forest Transitive Trust Capabilities Windows Server 2003 Active Directory introduced the capability to establish cross-forest transitive trusts between two disparate Active Directory forests. This capability allows two companies to share resources more easily, without actually merging the forests. Note that both forests must be running at Windows Server 2003 functional levels for the transitive portion of this trust to function properly. Forests in mixed mode can use the older, nontransitive explicit trust capability.

  • Active Directory Replication Compression Disable Support By default, all replication traffic between domain controllers in Active Directory is compressed to reduce network traffic. However, this compression can have the undesired effect of slowing down processor performance on the domain controllers. In Windows Server 2003 Active Directory, you have the option of turning off this functionality, disabling compression and saving processor cycles. This would normally be an option only for organizations with very fast connections between all their domain controllers.

  • Schema Attribute Deactivation Developers who write applications for Active Directory can take heart in the fact that Windows Server 2003's Active Directory implementation offers the ability to deactivate schema attributes, allowing custombuilt applications to utilize custom attributes without fear of conflict. In addition, attributes can be deactivated to reduce replication traffic.

  • Incremental Universal Group Membership Replication Windows 2000 previously had a major drawback in the use of universal groups. Membership in those groups was stored in a single, multivalued attribute in Active Directory. Essentially, what this meant was that any changes to membership in a universal group required a complete re-replication of all membership. In other words, if you had a universal group with 5,000 users, adding number 5,001 would require a major replication effort because all 5,001 users would be re-replicated across the forest. Windows Server 2003 simplifies this process and allows for incremental replication of universal group membership. In essence, only the 5,001st member is replicated in Windows Server 2003.

Active Directory in Application Mode (ADAM)

One additional function of Windows Server 2003 is the Active Directory in Application Mode (ADAM) product. AD was given the capability to run separate instances of itself as unique services. Active Directory in Application Mode allows specialized applications to utilize ADAM as their own directory service, negating the need for a new form of directory service for every critical application within an organization.

ADAM uses the same replication engine as Active Directory, follows the same X.500 structure, and is close enough to real AD functionality to allow it to be installed as a testbed for developers who design AD applications. Despite the similarities, however, ADAM runs as a separate service from the operating system, with its own schema and structure.

The real value to an ADAM implementation comes from its capability to utilize the security structure of the production domain(s), while maintaining its own directory structure. In fact, an instance of ADAM can run as a service on a Windows Server 2003 member server or even a Windows XP Professional workstation in a Windows NT domain. The ADAM would then utilize NT domain accounts for its own security.

ADAM functionality was developed in direct response to one of the main limitations in using Microsoft's Active Directory: the fact that the directory was so intrinsically tied to the NOS that applications which did not require the extra NOS-related functionality of AD were restricted in their particular directory needs. ADAM allows each application to have its own separate AD directory forest and allows for personalized modification of the directory, such as schema extensions, tailored replication (or lack of replication) needs, and other key directory needs.

One of the major advantages to ADAM also lies in the fact that multiple instances of ADAM can run on a single machine, each with its own unique name, port number, and separate binaries. In addition, ADAM can run on any version of Windows Server 2003 or even on Windows XP Professional for development purposes. Each instance of ADAM can utilize a separate, tailored schema.

ADAM is virtually indistinguishable from a normal NOS instance of Active Directory and consequently can be administered using the standard tools used for AD, such as ADSIEdit, LDP.exe, and the Microsoft Management Console (MMC) tools. In addition, user accounts can be created, unique replication topologies created, and all normal AD functionality can be performed on a tailored copy of an AD forest.

In short, ADAM provides applications with the advantages of the Active Directory environment, but without the NOS limitations that previously forced the implementation of multiple, cost-ineffective directories. Developers now can exploit the full functionality of Windows Server 2003's Active Directory without limitation, while at the same time assuming the numerous advantages of integration into a common security structure.

Additional Changes in Windows Server 2003

In addition to the changes listed in the preceding sections, Active Directory in Windows Server 2003 supports the following new features:

  • AD-Integrated DNS Zones in Application Partitions DNS zones that are Active Directory integrated are now stored in the application partition. This basically means that fewer objects need to be stored in AD, reducing replication concerns with DNS.

  • AD Lingering Objects Removal Objects listed in Active Directory that no longer exist can now be easily removed in Windows Server 2003.

  • AD Administration Enhancements Administrative tools have been enhanced in Windows Server 2003 to facilitate common tasks such as working with ACLs, finding objects, and selecting multiple OUs for tasks.


Summary

When Microsoft developed Windows Server 2003, the need arose for a common framework to tie in the various applications and frameworks. The success of Active Directory with Windows 2000 supplied Microsoft with the medium into that common framework. Along with the addition of new capabilities such as domain rename and other enhancements, Active Directory builds on its "road worthiness" and the real-world experience it gained with Windows 2000 to bring a robust, secure environment for networking services and functionality.


Best Practices

  • Design domains sparingly: Don't necessarily set up multiple domains for different remote offices or sites.

  • Purchase any external domain namespaces that theoretically could be bought and used on the Internet.

  • Strongly consider using Dynamic DNS in an AD environment.

  • Consider using cross-forest transitive trusts between two disparate Active Directory forests when merging the forests is not an option.

  • Place the infrastructure master role on a domain controller that isn't also a global catalog unless all domain controllers in the domain are global catalog servers or you are in a single domain environment.

  • Use the ntdsutil command-line utility to transfer OM roles in disaster recovery situations.

  • Use global groups to contain users in the domain in which they exist but also to grant access to resources in other trusted domains.

  • Use universal groups to contain users from any domain in the forest and to grant access to any resource in the forest.


Chapter 5. Designing a Windows Server 2003 Active Directory

In This Chapter

  • Active Directory Domain Design

  • Choosing Your Domain Namespace

  • New Domain Design Features in Windows Server 2003

  • Choosing Your Domain Structure

  • Single Domain Model

  • Multiple Domain Model

  • Multiple Trees in a Single Forest Model

  • Federated Forests Design Model

  • Peer-Root Domain Model

  • Placeholder Domain Model

  • Special-Purpose Domain Design Models

  • Renaming an Active Directory Domain

Proper design of a Windows Server 2003 Active Directory structure is a critical component in the successful deployment of the technology. Mistakes made in the design portion of Active Directory can prove to be costly and difficult to correct. Many assumptions about basic Active Directory domain and functional structure have been made, and many of them have been incorrect or based on erroneous information. Solid understanding of these components is vital, however, and anyone looking at Windows Server 2003 should keep this point in mind.

Active Directory was specifically designed to be scalable. This means that theoretically organizations of every shape and size should be able to implement the technology. For obvious reasons, this means that the structure of the Active Directory forest will vary from organization to organization.

In Windows Server 2003's Active Directory implementation, cross-forest trust capability has been added. This allows for the design of so-called federated forests, a new concept in Windows Server 2003. Federated forests are basically multiple forests with separate schemas and separate administrative teams joined via cross-forest transitive trusts. This allows for greater scalability and enables administrators to completely separate security boundaries within an organization.

In addition, several design decisions that were previously irreversible in Windows 2000, such as forest name and relative domain structure, have been updated to allow changes to take place. Now, an Active Directory domain structure can be renamed in the event of a merger or acquisition. The psychological factor alone of having to make a decision and not being able to change it has kept some organizations away from deploying Active Directory in the past. Now that those barriers have been removed, more organizations will be able to deploy Active Directory without fear of being painted into a corner later, so to speak.

This chapter focuses on best practices for Active Directory design, including a discussion of the specific elements that comprise Active Directory. Various domain design models for Active Directory are presented and identified with specific real-world scenarios. The domain rename procedure is outlined as well, to provide for an understanding of how the concept affects domain design decisions. In addition, step-by-step instructions are presented for several aspects of Windows Server 2003 domain design that have significantly changed since Windows 2000.


Active Directory Domain Design

Before any domain design decisions can be made, it is important to have a good grasp of Active Directory's domain structure and functionality. Windows 2000 administrators will recognize many of the key components, but some fairly major changes have been made in Windows Server 2003 that require a reintroduction to the domain design process. In addition, real-world experience with AD domain design has changed some of the assumptions that were made previously.

Domain Trusts

Windows Server 2003's Active Directory domains can be linked to each other through the use of a concept known as trusts. A trust is essentially a mechanism that allows resources in one domain to be accessible by authenticated users from another domain. As many administers will recall, domain trusts in NT 4.0 were one way, and not transitive. In other words, any resource sharing between multiple domains required numerous multiple-trust relationships. Trusts in Active Directory take a different approach than this "connect everything with trusts" approach. In Windows Server 2003's Active Directory, trusts are more powerful and simplistic at the same time. AD trusts take on many forms but typically fall into one of the four categories described in the following sections.

Transitive Trusts

Transitive trusts are automatic two-way trusts that exist between domains in Active Directory. These trusts connect resources between domains in Active Directory and are different from Windows NT trusts in that the trusts flow through from one domain to the other. In other words, if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A trusts Domain C. This flow greatly simplifies the trust relationships between Windows domains because it forgoes the need for multiple exponential trusts between each domain.

Explicit Trusts

An explicit trust is one that is set up manually between domains to provide for a specific path for authentication sharing between domains. This type of trust relationship can be one way or two way, depending on the needs of the environment. In other words, all trusts in NT 4.0 could have been defined as explicit trusts because they all are manually created and do not allow permissions to flow in the same way as transitive trusts do. The use of explicit trusts in Active Directory allows designers to have more flexibility and to be able to establish trusts with external and down-level domains. All trusts between Active Directory domains and NT domains are explicit trusts.

Shortcut Trusts

A shortcut trust is essentially an explicit trust that creates a shortcut between any two domains in a domain structure. For example, if a domain tree has multiple subdomains that are many layers deep, a shortcut trust can exist between two domains deep within the tree, similar to the shortcut trust shown in Figure 5.1. This relationship allows for increased connectivity between those two domains and decreases the number of hops required for authentication requests. Normally, those requests would have to travel up the transitive trust tree and back down again, thus increasing overhead.

Figure 5.1. Shortcut trusts minimize hops between domains.

The example in Figure 5.1 shows how a shortcut trust could theoretically be used to reduce the overhead involved in sharing resources between the two sales subdomains in the companyabc.com tree. You can find more information on these trusts in the individual design model sections later in this chapter.

Cross-Forest Transitive Trusts

Cross-forest transitive trusts are essentially two-way transitive trusts that exist between two disparate Active Directory forests. While explicit trusts between separate AD domains in separate forests were possible in Windows 2000, the cross-forest trusts in Windows Server 2003 allow for two-way transitive trusts to exist between two separate forests. More information can be found about this new variety of trust later in this chapter.


Choosing Your Domain Namespace

The first step in the actual design of the Active Directory structure is the decision on a common domain name system (DNS) namespace that Active Directory will occupy. Active Directory revolves around, and is inseparable from, DNS, and this decision is one of the most important ones to make. The namespace chosen can be as straightforward as microsoft.com, for example, or it can be more complex. Multiple factors must be considered, however, before this decision can be made. Is it better to register an AD namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered internal namespace? Is it necessary to tie in multiple namespaces into the same forest? These and other questions must be answered before the design process can proceed.

External (Published) Namespace

The simplest method of implementing an Active Directory structure is through the use of a single, common DNS namespace that reflects the company's name and is registered on the Internet. Microsoft.com is an obvious example, and a myriad of other possibilities exist as well. Several advantages to a published namespace are that it is readily accessible from the Internet and there is less confusion on the end user's part in regards to the location on the network and on the Internet. For example, a user named Peter Pham working for the CompanyABC Corporation will be represented in the network through its user principal name (UPN) as Peter@companyabc.com. This name can be set up to exactly match his email address, limiting confusion for the end user.

The limitations to this type of namespace strategy are primarily security based. Publishing your Active Directory namespace leaves potential hackers with the name of your domain system and part of what is needed to compromise user accounts. Administering your firewall to block internal DNS queries also becomes less intuitive when the namespace is the same as the published Internet namespace for the organization. If the namespaces were separate, for example, a simple rule could be written to block any traffic to the internal domain structure. Another limitation would arise if an organization currently employs multiple namespaces to identify itself, and all those namespaces need to be joined into the same forest; in this case, a common namespace design is not an option. Mergers and acquisitions or even multiple business units within the same corporate parent can present these types of problems.

Internal Namespace

If desired or required by your organization, the namespace that the Active Directory structure inhabits can be internal, or not published to the Internet. Using internal namespaces adds a layer of complexity to your network because users' UPNs are different from their email addresses. However, the increase in security that is realized from this design is also a factor that leads organizations to choose this route. Another factor that may influence your decision to choose an Internet namespace is that you are no longer limited to the Internic standard namespaces of .com, .net, .biz, .info, and so on. For example, many organizations use the .internal namespace, or some other namespace that is not used on the Internet.

Keep in mind that it is important to secure an internal namespace from registration anywhere on the Internet other than in your own network. In other words, if an organization registers internalnetwork.net, and another organization on the Internet registers the same domain name for its network, there could be naming conflicts with applications and other systems that perform DNS lookups against your forest. For example, if an application on a laptop usually attempts to access an internal namespace but then tries to access it remotely through an ISP, the ISP's DNS will forward you to the registered DNS name on the Internet. In a nutshell, if you are going to design your domain with an unpublished namespace but use a standard such as .net or .org that someone else could theoretically register, it is best to register and reserve that domain but not point it anywhere. Another common tactic is to name your domain something that will never be published, such as a root with your company's stock ticker symbol (for example, network.msft), or by utilizing the .internal suffix, which has been specifically reserved for internal use only.


New Domain Design Features in Windows Server 2003

Many administrators have already become accustomed to Active Directory design and are familiar with the basic layout and characteristics of the Active Directory structure in Windows 2000. Windows Server 2003 introduces some dramatic changes to Active Directory, which changes some fundamental components of Active Directory and allows for greater flexibility in domain design. Among these changes are the following:

  • Domain rename function The capability to rename a domain in a Windows Server 2003 forest has opened up a new field of possibilities for the design and potential redesign of Active Directory domain structures. Previously, stern caveats were issued about the inability to rename domains or change the overall structure of an Active Directory forest. With the domain rename functionality present in Windows Server 2003's Active Directory implementation, these limitations are lifted, and designers can take heart in the fact that design changes can be made after implementation. Having this ability does not change the fact that it is still wise to plan out your domain design thoroughly, however. Not having to make changes to domain names or reposition domains in a forest is much easier than having to go through the domain rename process. Just knowing that such functionality exists, however, is a breath of fresh air for designers.

  • Cross-forest transitive trusts New in Windows Server 2003, the concept of cross-forest transitive trusts lessens domain designers' connectivity worries. In the past, some administrators balked at the limitations of collaboration within Windows 2000 Active Directory structures. The cross-forest transitive trust capability of Active Directory negates those concerns because multiple Active Directory forests can now be joined via cross-forest trusts that are transitive, rather than explicit, in nature. The combination of these forests is known in the Microsoft world as federated forests.

  • Domain controller promotion from media The capability to promote remote servers to domain controllers via a CD image of the global catalog helps to limit replication traffic and the time associated with establishing remote domain controllers. There have been some recorded instances of DC promotions taking several days, and even up to a week, to replicate the initial global catalog information in Windows 2000. Windows Server 2003 solves this issue by providing you with the ability to save the global catalog to media (like a CD-ROM), ship it to a remote site, and finally run domain controller promotion (dcpromo) and insert the data disk with the directory on it for restoration. Only the delta, or changes made since media creation, are then replicated, saving time and bandwidth. The effect of this on domain design creation is reflected in reduced setup times and increased flexibility of global catalog domain controller placement.

  • Administrative enhancements New "headless" management functionality reduces the need to have local administrators present at each site. Essentially, Terminal Services Remote Administration has been built into all Windows Server 2003 installs, facilitating remote administration. Terminal Services users will note how easy it is to take control of remote machines and administer them as if they were at the keyboard. No more driving 300 miles to your Death Valley branch office to reboot a server. Because all domain controllers, member servers, application servers, and so on will have Terminal Services capability, designers will have more flexibility in arranging server layout.


Choosing Your Domain Structure

There is a basic tenet to consider when designing the Active Directory domain structure. Start simple, and then expand only if expansion is necessary to address a specific need. This concept is, by and large, the most important concept to remember when you're designing Active Directory components. In regard to domain design, this means you should always start the design process with a single domain and then add on to your design if your organizational concerns dictate that you do so. Following this basic philosophy during the design process will reduce headaches down the road.

When you're designing the Active Directory, you must contemplate a common framework for diagrams. In Active Directory, for example, domains are often pictorially represented by triangles, as shown in Figure 5.2. So, when beginning your design, start with a single triangle.

Figure 5.2. Domain diagram representation as a triangle.

In this example, the fictional company named CompanyABC has begun the process of domain design. Depending on its unique needs, CompanyABC may decide to expand upon that model or keep it simplistic. These decisions should be made with a detailed knowledge of the different domain design models and the environments in which they work best.

Active Directory was designed to be a flexible, forgiving directory services implementation. This is even more true with Windows Server 2003's Active Directory implementation. Consequently, there are multiple design models available to choose from, depending on the individual needs of organizations. The major design models are as follows:

  • Single domain model

  • Multiple domain model

  • Multiple trees in a single forest model

  • Federated forests design model

  • Peer-root model

  • Placeholder domain model

  • Special-purpose domains

In reality, not all AD structures fall underneath these categories because the possibilities exist for numerous variations and mutations of AD structure. However, most domain structures either fall into these categories or are a hybrid model, possessing traits of two different models. Out of all these models, however, the single domain model is the most common design model and also happens to be the easiest to deploy.


Single Domain Model

The most basic of all Active Directory structures is the single domain model; this type of domain structure comes with one major advantage over the other models: simplicity. A single security boundary defines the borders of the domain, and all objects are located within that boundary. The establishment of trust relationships between other domains is not necessary, and implementation of technologies such as Group Policies is made easier by the simple structure. Many organizations that have lived with a multiple domain NT structure may think that they cannot consolidate on a single domain model. However, more organizations than not can take advantage of this design because Active Directory has been simplified and its capability to span multiple physical boundaries has been enhanced.

Choosing the Single Domain Model

The single domain model is ideal for many organizations and can be modified to fit many more. A single domain structure possesses multiple advantages, first and foremost being simplicity. As any administrator or engineer who has done work in the trenches can confirm, often the simplest design works the best. Adding unnecessary complexity to systems' architecture introduces potential risk and makes troubleshooting these systems more difficult. Consequently, consolidating complex domain structures such as NT 4.0 into a simpler single domain Active Directory structure can reduce the costs of administration and minimize headaches in the process.

Another advantage realized by the creation of a single domain is the attainment of centralized administration. Many organizations with a strong central IT structure want the capability to consolidate control over the entire IT and user structure. NT domains were notoriously lacking in their capability to scale to these levels, and the types of central control that organizations wanted were not available. Active Directory and, specifically, the single domain model allows for a high level of administrative control and the ability to delegate tasks to lower sets of administrators. This has proven to be a strong draw to Active Directory.

Not all Active Directory structures can be composed of a single domain, however, and some factors may limit an organization's ability to adopt a single domain structure. If these factors affect your organization, you might need to begin expanding your domain model to include other domains in the forest and a different domain design. For example, the single security boundary formed by a single domain may not be exactly what your organization needs. Although OUs can be used to delegate administration of security elements, the domain itself is the security boundary in Active Directory structures. If the security lines within your organization need to follow exact boundaries, a single domain may not be for you. For example, if your HR department requires that no users from IT have access to resources within its environment, you will need to expand your domain structure to accommodate the additional security concerns.

Another disadvantage of the single domain model is that a single domain in a forest necessitates that the computer with the role of schema master is located in that domain. This places the schema master within the domain that contains all the user accounts. Although access to the schema master can be strictly controlled through proper administration, your risk of schema exposure is greater when the schema master role resides in a user domain. For example, members of the domain administrators group could override the security of the schema administrators group and add their account to that group. If this design model poses problems for you as an organization, design models that separate the schema master into a placeholder domain can do the trick. The placeholder domain model is described in more detail later in this chapter.

A Single Domain Real-World Design Example

To illustrate a good example of an organization that would logically choose a single domain model, let's consider fictional Company A. Company A is a 500-user organization with a central office located in Minneapolis. A few smaller branch offices are scattered throughout the Midwest, but all help desk administration is centralized at the company headquarters. Company A currently utilizes a single NT user domain and has multiple resource domains in various locations across the country.

The IT team in Minneapolis is designing an Active Directory structure and wants to centralize administration at corporate headquarters. Branch offices should have the capability to change passwords and clear print jobs locally, but should have no other form of administrative privilege on the network.

During the Active Directory design process, Company A started with a single Active Directory forest, domain, and namespace named companya.net. Organizational units for each branch office were added to delegate password-change control and print administration to those offices.

Current NT 4.0 domains were consolidated into the Active Directory structure, as shown in Figure 5.3. Company A could not justify the existence of additional domains because their security model was centralized, and it did not have any far-flung geographical locations with slow link speeds to the main office or any other similar constraints that required additional domains.

Figure 5.3. Active Directory structure with organizational unit structure.

Delegation of password-change control and other local administrative functions was granted to individuals in each specific geographical OU, which gave those administrators permissions specific to only resources within their own group but maintained central administrative control in Minneapolis. A detailed discussion of organizational unit design is covered in Chapter 6, "Designing Organizational Unit and Group Structure."

Several Active Directory sites were created to control the frequency of replication. A site was positioned to correspond with each separate geographical area, creating a site structure similar to the one shown in Figure 5.4.

Figure 5.4. Site structure created by geographical locations.

Creating the separate sites helped to throttle replication traffic and reduce the load placed on the WAN links between the sites. For more details about site links and replication, see Chapter 7, "Active Directory Infrastructure."

This type of single domain design is ideal for the type of organization described in this section and actually can be used for many other types of organizations, large and small. Because delegation of administration is now accomplished through the use of OUs and Group Policy objects, and the throttling of replication is accomplished through AD sites, the number of reasons for organizations to use multiple domains has been reduced.


Multiple Domain Model

For various reasons, organizations may need to add more than one domain to their environment but preserve the functionality that is inherent in a single forest. When this occurs, the addition of one or multiple domains into the forest is warranted. Domain addition should not be taken lightly, however, and proper consideration must be given to the particular characteristics of multiple domain models.

By default, two-way transitive trusts exist between subdomains and domains in Active Directory. Bear in mind, however, that this does not mean that resource access is automatically granted to members of other domains. A user in subdomain B is not automatically granted any rights in domain A; the rights need to be explicitly defined through the use of groups. Understanding this concept will help to determine the logistics of domain addition.

When to Add Additional Domains

As previously mentioned, it is advisable to begin your Windows Server 2003 Active Directory design with a single domain and then add domains only when absolutely necessary. Adding child domains to an existing domain structure may become necessary if the following traits exist within an infrastructure:

  • Decentralized administration If different branches of an organization generally manage their own IT structure and there are no future plans to consolidate them into a centralized model, multiple interconnected domains may be ideal. Each domain acts as a security boundary for most types of activity and can be set up to disallow administration from escaping the boundaries of domains. This approach operates in much the same way as NT domains and inherits many of the limitations associated with them as well. In other words, it is better to try to centralize administration before deploying Active Directory because you will gain more of AD's advantages.

  • Geographic limitations If extremely slow or unreliable links or great geographical distances separate different parts of your company, it may be wise to segment the user population into separate domains. This will help to limit replication activity between domains and also make it easier to provide worktime support for distant time zones. Keep in mind that slow links by themselves do not necessitate the creation of multiple domains, as Windows Server 2003 Active Directory uses the concept of Active Directory sites to throttle replication across slow links. The main reason that might exist for domain creation for geographical reasons is administrative flexibility. In other words, if there is a problem with the network in Japan, a Japanese administrator will have more power to administer the Asia domain and will not need to call the North American administrator in the middle of the night.

  • Unique DNS namespace considerations If two organizational entities want to use their Internet-registered namespace for Active Directory but use a common forest, such as hotmail.com or microsoft.com, those domains must be added as separate domains. This type of domain model is described more fully in the section "Multiple Trees in a Single Forest Model" later in this chapter.

  • Special password policies Because password policies are set on a domain level, if any specific password policies must be set differently between domains, separate domains must be set up to segregate those policies. This is rarely a real-life design issue that by itself creates a new domain, but knowledge of this limitation will help in the design process.

  • Enhanced security concerns Depending on the needs of your organization, separating the schema master role into a domain separate from your users may be applicable. In this case, the single domain model would not be applicable, and a model such as the peer-root or placeholder domain would be more appropriate.

When contemplating additional domains, remember the mantra "Simplicity is best." However, if during the design process, the specific need arises to add domains, proper design is still warranted, or your environment will run the risk of looking like the type of messed-up NT domain structure that's best avoided.

A Multiple Domain Real-World Design Example

The following example illustrates an organization that would have grounds to establish multiple domains. Company B is an engineering company based in York, Pennsylvania. Administration for all branch locations is currently centralized in the home office, and OUs and Group Policies are used for delegation of lower-level tasks. Recently, the company acquired two separate companies named Subsidiary A and Subsidiary B; each contains its own IT department and operates in separate geographical areas. Company B decided to implement Active Directory as part of a Windows Server 2003 implementation and wanted to include the two acquired companies into a single common forest.

Because each acquired company possesses its own IT department and there are no immediate plans to consolidate those functions centrally, Company B decided to deploy an Active Directory structure with two subdomains for Subsidiary A and Subsidiary B, as shown in Figure 5.5.

Figure 5.5. Active Directory with two subdomains.

This design model allowed for a certain degree of administrative freedom with the newly acquired subsidiaries but also allowed for a common forest and schema to be used and kept the domains within the same DNS namespace.

This design model has the particular advantage of being politically easier to implement than consolidation of existing domains. Branch offices and subsidiary companies can keep their own domain structure and security boundaries, and their IT teams can retain a greater deal of administrative autonomy.

Be warned, however, that consolidation of NT domains into fewer domains is a key feature of Active Directory, so the addition of domains purely for political reasons adds complexity and potentially unnecessary infrastructure. It is therefore very important to consider the alternatives before deciding on this design model.


Multiple Trees in a Single Forest Model

Let's say that your organization would like to look at Active Directory and wants to use an external namespace for your design. However, your environment currently uses multiple DNS namespaces and needs to integrate them into the same design. Contrary to popular misconception, integration of these namespaces into a single AD forest can be done through the use of multiple trees that exist in one forest. One of the most misunderstood characteristics of Active Directory is the difference between a contiguous forest and a contiguous DNS namespace. Many people do not realize that multiple DNS namespaces can be integrated into a single Active Directory forest as separate trees in the forest. For example, Figure 5.6 shows how Microsoft could theoretically organize several Active Directory domains that share the same forest but reside in different DNS namespaces.

Figure 5.6. Sample Active Directory forest with multiple unique trees within the same forest.

[View full size image]

Only one domain in this design is the forest root, in this case microsoft.com, and only this domain controls access to the forest schema. All other domains, including subdomains of microsoft.com and the other domains that occupy different DNS structures, are members of the same forest. All trust relationships between the domains are transitive, and trusts flow from one domain to another.

When to Deploy a Multiple Tree Domain Model

If an organization currently operates multiple units under separate DNS namespaces, one option may be to consider a design such as this one. It is important to understand, however, that simply using multiple DNS namespaces does not automatically qualify you as a candidate for this domain design. For example, you could own five separate DNS namespaces and instead decide to create an Active Directory structure based on a new namespace that is contiguous throughout your organization. Consolidating your Active Directory under this single domain could simplify the logical structure of your environment while keeping your DNS namespaces separate from Active Directory.

If your organization makes extensive use of its separate namespaces, you may want to consider a design like this. Each domain tree in the forest can then maintain a certain degree of autonomy, both perceived and real. Often, this type of design will seek to satisfy even the most paranoid of branch office administrators who demand complete control over their entire IT structure.

A Multiple Tree Domain Real-World Design Example

To gain a greater understanding of the times an organization might use this particular design model, examine the following AD structure. City A is a local county governmental organization with a loose-knit network of semi-independent city offices such as the police and fire departments that are spread out around the city. Each department currently uses a DNS namespace for name resolution to all hosts and user accounts local to itself, which provides different email addresses for users located in the fire department, police department, and other branches. The following namespaces are used within the city's infrastructure:

  • citya.org

  • firedeptcitya.org

  • policeofcitya.org

  • cityalibrary.org

The decision was made to merge the existing network environments into a single Active Directory forest that will accommodate the existing departmental namespaces but maintain a common schema and forest root. To accomplish this, Active Directory was established with citya.org as the namespace for the root domain. The additional domains were added to the forest as separate trees but with a shared schema, as shown in Figure 5.7.

Figure 5.7. Single Active Directory forest with separate directory trees for departments.

[View full size image]

The individual departments were able to maintain control over their individual security and are disallowed from making changes in domains outside their control. The common forest schema and global catalog helped to increase collaboration between the varying organizations and allow for a certain amount of central administration.

This type of domain design is logically a bit messier but technically carries the same functionality as any other single forest design model. All the domains are set up with two-way transitive trusts to the root domain and share a common schema and global catalog. The difference lies in the fact that they all utilize separate DNS namespaces, a fact that must also be reflected in the zones that exist in DNS.


Federated Forests Design Model

A new feature of Windows Server 2003's Active Directory implementation is the addition of cross-forest transitive trusts. In essence, this allows you to establish transitive trusts between two forests with completely separate schemas that allow users between the forests to share information and to authenticate users.

The capability to perform cross-forest trusts and synchronization is not automatic, however, because the forest functionality of each forest must be brought up to Windows Server 2003 functionality levels. What this means is that all domain controllers in each forest must first be upgraded to Windows Server 2003 before any cross-forest trusts can be established. This can prove to be a difficult prospect for organizations already deployed with Windows 2000. Consequently, the federated forest design model is easier to consider if you do not currently have an Active Directory structure in place.

The federated forest design model is ideal for two different situations. One is to unite two disparate Active Directory structures in situations that arise from corporate acquisitions, mergers, and other forms of organizational restructuring. In these cases, two AD forests need to be linked to exchange information. For example, a corporate merger between two large organizations with fully populated Active Directory forests could take advantage of this capability and link their two environments, as shown in Figure 5.8, without the need for complex domain migration tools.

Figure 5.8. Cross-forest trust between two completely different organizations needing to share resources.

In this example, users in both forests now can access information in each other's forests through the two-way cross-forest trust set up between each forest's root.

Note

Windows Server 2003 R2 introduced the concept of Active Directory Federation Services (ADFS), which effectively makes it easier to administer and provision users in disparate forests. More information on ADFS can be found in Chapter 8, "Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories."

The second type of scenario in which this form of forest design could be chosen is one in which absolute security and ownership of IT structure are required by different divisions or subsidiaries within an organization, but exchange of information is also required. For example, an aeronautics organization could set up two AD forests, one for the civilian branch of its operations and one for the military branch. This would effectively segregate the two environments, giving each department complete control over its environment. A one- or two-way cross-forest trust could then be set up to exchange and synchronize information between the two forests to facilitate communication exchange.

This type of design is sometimes precipitated by a need for the complete isolation of security between different branches of an organization. Since the release of Active Directory in Windows 2000, several inter-domain security vulnerabilities have been uncovered that effectively set the true security boundary at the forest level. One in particular takes advantage of the SIDHistory attribute to allow a domain administrator in a trusted domain in the forest to mimic and effectively seize the schema admin or enterprise admin roles. With these vulnerabilities in mind, some organizations may choose separate forests, and simply set up trusts between the forests that are specifically designed to strip off the SIDHistory of a user.

In Figure 5.9, a one-way cross-forest transitive trust with SIDHistory-filtering enabled was set up between the civilian branch and the military branch of the sample aeronautics organization. In this example, this setup would allow only accounts from the military branch to be trusted in the civilian branch, in essence giving the military branch users the ability to access files in both forests. As with NT domains, cross-forest trusts are one-way by default. Unlike NT trusts, however, cross-forest trusts in Windows Server 2003 can be transitive if both forests are running at Windows Server 2003 functional levels. To set up two-way transitive trusts, you must establish two one-way trusts between the two forest roots.

Figure 5.9. One-way cross-forest trust.

Determining When to Choose Federated Forests

The concept of federated forests greatly enhances the abilities of Active Directory forests to exchange information with other environments. In addition, organizations that were reluctant to implement AD because of the lack of a solid security boundary between domains can now take heart in the capability of the federated forest design to allow specific departments or areas to have complete control over their own forests, while allowing for the transfer of information between the domains.

A Federated Forest Real-World Design Example

To illustrate a good example of an organization that would choose a federated forest design model, let's consider fictional Conglomerate A, which is a food distributor with multiple sites worldwide. It currently operates a Windows Server 2003 Active Directory implementation across its entire organization. All computers are members of the forest with a namespace of companyb.net. A root domain exists for conglomeratea.net, but it is not populated because all users exist in one of three subdomains: asia, europe, and na.

Conglomerate A has recently entered into a joint venture with Supplier A and would like to facilitate the sharing of information between the two companies. Supplier A also currently operates in a Windows Server 2003 Active Directory environment and keeps all user and computer accounts in an Active Directory forest that is composed of two domains in the suppliera.com namespace and a separate tree with a DNS namespace of supplierabranch.org that reflects a certain function of one of its branches.

The decision was made to create a cross-forest trust between the two forests so that credentials from one forest are trusted by the other forest and information can be exchanged. The cross-forest trust was put into place between the root domains in each forest, as shown in Figure 5.10.

Figure 5.10. Cross-forest trust between root domains in each forest.

[View full size image]

Remember, that just as in NT 4.0, a trust does not automatically grant any permissions in other domains or forests; it simply allows for resources to be implicitly shared. Administrators from the trusting domain still need to manually grant access. In our example, administrators in both forests can decide what resources will be shared and can configure their environment as such.


Peer-Root Domain Model

The schema is the most critical component of Active Directory and should therefore be protected and guarded closely. Unauthorized access to the schema master domain controller for a forest can cause some serious problems and is probably the best way to corrupt the entire directory. Needless to say, segregation of the keys to the schema from the user base is a wise option to consider. From this concept was born the peer-root domain model, shown in Figure 5.11.

Figure 5.11. Peer-root domain model with an unpopulated forest root.

In short, the peer-root domain model makes use of an unpopulated forest root domain that exists solely to segregate the schema master function from the rest of the network.

In Figure 5.11, the companyabc.com domain is used for all user and computer accounts, whereas the abcschema.root domain is the peer-root domain that holds the schema master role for the company. Most users would not even be aware of the fact that this domain exists, which makes it even more secure.

The one major disadvantage to this design model lies in the hardware costs. Because a separate domain is necessary, at least one extra domain controller will be needed as part of the design plan, and preferably two for redundancy issues. This domain controller for the peer-root domain will not need to be the speediest machine because it will not perform much work, but it should definitely be made redundant, because the forest-specific FSMO roles will be handled by the machine.

Determining When to Choose the Peer-Root Model

Security needs vary from organization to organization. A company that performs topsecret work for the military is going to have drastically different security issues than a company that manufactures rubber duckies. Consequently, if the needs of your organization require a greater amount of security, the peer-root domain model may be the right one for you.

An additional advantage that this type of environment gives you is the flexibility to rename domains, add domains, and essentially move in and out of subdomains without the need to rename the forest. Although the domain rename tool exists in Windows Server 2003, undertaking this task is still complicated, and using the peer-root model can help to simplify changes. In a merger, for example, if your peer root is named root.network and all your resource domains are located in companyabc.com in the same forest, it becomes much easier to add companya.net into your forest by joining it to the root.network domain.

The beauty of the peer-root domain model is that it can be incorporated into any one of the previously defined domain models. For example, a large grouping of trees with published namespaces can have a forest root with any name desired.

The example shown in Figure 5.12 demonstrates how this type of environment could conceivably be configured. The flexibility of Active Directory is not limited by this design model because the options available for multiple configurations still exist.

Figure 5.12. The peer-root domain model using different domain tree names throughout the forest.

[View full size image]

Of course, many organizations often cannot justify the increased hardware costs, and this type of design model can prove to be more costly. Realistically, two domain controllers need to be established in the root domain to handle authentication requests and to provide for redundancy within the domain. Keeping these costs in mind, it is important to align your organization's security requirements with the cost-benefit ratio of this design model.

A Real-World Peer-Root Domain Design Example

Company D is a biomedical corporation centered in the San Francisco Bay area. Infrastructure security is highly important for the organization, and the company needs to ensure that directory information is safe and secure in the network environment. The IT organization is centralized, and most employees are located at the main headquarters building.

The administrators of Company D originally chose Active Directory and Windows Server 2003 to provide for robust security for their environment and to take advantage of the increased functionality. However, management was concerned about limiting access to vital components of the directory service such as the schema. Further investigation into the varying domain design models for Active Directory uncovered the peer-root domain model as a fully functional substitute to the single domain model, but with the added schema security that they desired. This resulted in a forest structure similar to the one shown in Figure 5.13.

Figure 5.13. Peer-root domain with schema security for added protection and integrity.

Organizational units were created for each department and placed in the companyd.com domain. The only user account in the rootd.peer domain is the Administrator account for the forest. Access to this account was limited to a choice group of high-level administrators. This helped to control access to the schema root for the security-conscious organization and provided for the simplicity of a single domain environment for its users.


Placeholder Domain Model

The placeholder domain model, also known as the sterile parent domain model, deserves special mention because of its combination of a single namespace/multiple domain model and the peer-root model. Simply put, the placeholder domain model, shown in Figure 5.14, is composed of an unoccupied domain as the forest root, with multiple subdomains populated with user accounts and other objects.

Figure 5.14. Unpopulated placeholder domain.

There are two distinct advantages to this design. First, as with the peer-root model, the schema is separate from the user domains, thus limiting their exposure and helping to protect the schema. Second, the namespace for the user accounts is consistent in the namespace, thus mitigating any potential political issues. In other words, because all users in all locations are at the same logical level in the domain structure, no one group will feel superior or inferior to another. This issue may seem trite, but the psychological nature of humans is finicky, and you may find that this design offers advantages for certain organizations.

A Placeholder Domain Real-World Design Example

Company E is an architectural firm with major offices located in New York, Chicago, Los Angeles, Sao Paulo, Rio de Janeiro, Berlin, Paris, London, Tokyo, Singapore, and Hong Kong. Administration is centralized in New York, but regional administration takes place in Rio de Janeiro, London, and Tokyo. The company has recently migrated to Active Directory and has chosen to deploy a placeholder domain model for its organization that looks similar to Figure 5.15.

Figure 5.15. Complex Active Directory placeholder domain structure.

[View full size image]

All users authenticate to geographically centric subdomains. In addition, the administrators in New York have segregated the schema master function into the placeholder domain, limiting its exposure and have limited access to this domain to a small group of high-level administrators. Each domain is logically oriented as well, to give the impression of autonomy to each geographical unit.


Special-Purpose Domain Design Models

A special-purpose domain or forest is one that is set up to serve a specific need. For example, your organization may set up a special-purpose domain to house outside contractors or temporary workers to limit their exposure to the main Active Directory forest. In addition, trust relationships could be established between this domain or domains to allow for resource access.

Generally, there has to be a good reason before additional domains are deployed in Active Directory. Overhead is increased with each domain that is added to an environment, and your logical network structure begins to look convoluted. However, in some unique cases, a special-purpose domain may become necessary.

Another possible use for a separate special-purpose domain structure is to house a directory servicecapable application that requires itself, for security or other reasons, to have exclusive access to the schema. In other words, if your HR department runs an application that stores confidential employee information in an application that utilizes an LDAP-compliant directory, such as Active Directory, a domain could be set up for that application alone. A cross-forest trust relationship can be established to allow for the sharing of information between the two environments. This type of situation is rarer because most of these applications make use of their own directory, but it is possible. Because the Active Directory schema must be unique across the forest, this would preclude the use of a single forest if these applications require exclusive access or utilize common schema attributes. This type of functionality can be realized with the use of Active Directory in Application Mode (ADAM), which is further elaborated in Chapter 4, "Active Directory Primer."

A Special-Purpose Domain Real-World Design Example

Company E is a computer consulting firm headquartered in Morioka, Japan. Most consulting work is performed by full-time Company E employees; however, some outside contractors are brought in from time to time to help on projects. The company had already deployed Active Directory for the internal organization, but was concerned about opening access to the forest for any non-employees of the company. Consequently, a single domain Active Directory implementation was created for the non-employees to use. A cross-forest transitive trust was established between this domain and the internal forest, and access to resources such as file and print were delegated and controlled by the central IT organization.

Users in the contractor domain can access resources in the main companye.com domain, but only those that they are specifically granted access to. In addition, the exposure that the main companye.com domain receives from non-employees is greatly reduced.


Renaming an Active Directory Domain

Active Directory in Windows Server 2003 gives domain designers the flexibility to rename their domain namespace and/or splice domains in a forest to different locations within a forest. This capability gives Active Directory great new functionality because design changes can be made because of corporate mergers or organizational changes.

Domain rename supports renaming either the Active Directory namespace (for example, companyabc.com) or the NetBIOS (NT) domain name or both. The procedure is a rather brute-force process, however, and should not be considered to be a routine operation.

The domain rename functionality in Windows Server 2003 is mainly a psychological factor because the prerequisites for deploying domain rename make it unlikely to be widely performed, at least in the initial stages of Windows Server 2003 adoption. Domain rename offers long-term answers to the previous barriers to Active Directory adoption, which revolved around the fact that organizations did not want to be locked in to any decisions that could not be changed. Because a Windows 2000 Active Directory namespace decision was irreversible, this effectively put many decision-makers on edge, as they did not want to "paint themselves into a corner," so to speak. Domain rename removes this stipulation and makes Active Directory adoption much more palatable to decision-makers within an organization.

Domain Rename Limitations

Domain rename has several limitations. It is important to understand the following restrictions before considering a domain rename operation:

  • Cannot reduce the number of domains in a forest The domain rename tool cannot be used to drop additional domains from a forest. For example, if a forest is composed of four domains, there must be four domains remaining after the procedure is complete. This type of domain consolidation role can be performed only through the use of other tools, such as the Active Directory Migration Tool, which is covered in detail in Chapters 16, "Migrating from Windows NT4 to Windows Server 2003," and 17, "Migrating from Windows 2000 to Windows Server 2003."

  • The current root domain cannot be demoted Although the domain rename tool can splice and transplant domains from one portion of an Active Directory namespace to another, it cannot fundamentally change the root domain in a tree. A root domain can be renamed, however.

  • Cannot transfer current domain names in one cycle A production domain cannot be named the same as another production domain that exists in a forest. You need to run the domain rename procedure twice to achieve this type of desired functionality.

Note

Previous iterations of Windows Server 2003 limited the domain rename capabilities to AD schemas that had not been extended with Microsoft Exchange Server. However, this is no longer the case with Windows Server 2003 SP1/R2 and Exchange Server 2003 SP1/SP2 environments.

Domain Rename Prerequisites

In addition to the limitations of the domain rename tool, specific prerequisites for domain rename must be met before a domain can be renamed. These prerequisites are as follows:

  • The entire forest must be in Windows Server 2003 Functional mode One of the largest hurdles to overcome before renaming a domain is the fact that all domain controllers in the domain must be first upgraded or replaced with Windows Server 2003 and the forest functional level raised to Windows Server 2003 functionality. This reason alone will most likely be the biggest limiting factor, at least in the initial adoption period of Windows Server 2003.

  • New DNS zones must be created The DNS server(s) for a domain must have a zone added for the new domain namespace to which the domain will be renamed. The exception is if the domain rename procedure will be renaming only the NetBIOS domain.

  • Domain rename must run from a console server A member Windows Server 2003 computer (not a domain controller) must serve as the console server for the domain rename procedure. All domain rename operations are run from this one box.

  • Shortcut trust relationships may need to be created Any domains that will be "spliced" into a new location in the Active Directory forest will need to have a shortcut trust established between itself and the parent domain where it will be transplanted.

Renaming a Domain

The domain rename procedure, from the back end, is not extremely complex. Most of the barriers to domain renaming, aside from the limitations and prerequisites listed in the preceding section, come in the form of the disruption to the forest that is caused by the reboots applied to all the computers in the forest.

After the prerequisites have been satisfied, the domain rename process can proceed. The entire domain rename process is accomplished through six basic steps. As previously mentioned, however, this routine is rather harsh on the network because it causes down-time to a network infrastructure and should not be considered to be a common operation.

Step 1: List Current Forest Description

The tool used for domain rename is known as Rendom (which, ironically, is automatically changed to Random in Microsoft spell-checkers). Rendom has several flags that are used in import and export operations. The first procedure run from the console server is rendom /list, which locates the domain controllers for a domain and parses all domain-naming information into an XML document named Domainlist.xml, as illustrated in Figure 5.16.

Figure 5.16. Forest description XML document.

[View full size image]

This XML document can easily be modified by any text editor such as Notepad and, as will become evident, is central to the domain rename procedure.

Step 2: Modify Forest Description with New Domain Name(s)

The XML file generated by the /list flag must be modified with the new domain-naming information. For example, if CompanyABC is changing its name to CompanyXYZ, all references to companyabc in the XML list illustrated in Figure 5.16 are changed to companyxyz. This includes the NetBIOS and DNS names.

Step 3: Upload Rename Script to DCs

After the XML document is updated with the new domain information, it can be uploaded to all domain controllers in a forest through the use of the rendom /upload command. This procedure copies the instructions and new domain information up to all domain controllers within a forest.

Step 4: Prepare DCs for Domain Rename

Domain rename is a thorough process because it is absolutely necessary that all domain controllers in a forest receive the update information. It is therefore necessary to run rendom /prepare to initiate a preparation process that checks to see if every single domain controller listed in Active Directory responds and signifies that it is ready for the migration. If every single domain controller does not respond, the prepare function fails and must be restarted. This precaution exists to keep domain controllers that are powered down, or not accessible across the network, from coming up at a later time and attempting to service clients on the old domain name.

Step 5: Execute Domain Rename Procedure

After all domain controllers respond positively to the prepare operation, you can initiate the actual domain rename by running the rendom /execute command from the console server. Before the execute command is run, there are actually no changes made to the production environment. However, as the command is run, all domain controllers execute the changes and automatically reboot. You then must establish a method of rebooting all member servers, workstations, and other client machines and then reboot them all twice to ensure that all services receive the domain-naming change.

Note

Any Windows NT clients need to be manually rejoined to the domain following any domain rename procedure because they do not support automatic rejoin functionality.

Step 6: Post-Rename Tasks

The final step in the Rendom task is to run the rendom /clean operation, which will remove temporary files created on the domain controller and return the domain to a normal operating state.

In addition to the cleanup tasks, you need to effectively rename each domain controller, to change its primary DNS suffix. Each domain controller needs to go through this operation, which you run via the netdom command-line utility. The following steps outline the renaming of a domain controller:

1. | Open a Command Prompt window (choose Start, Run, and then type cmd.exe).
2. | Type netdom computername OldServerName /add:NewServerName.
3. | Type netdom computername OldServerName /makeprimary:NewServerName.
4. | Restart the server.
5. | Type netdom computername NewServerName /remove:OldServerName.

You run all the preceding commands from the command line. Replace the generic designators OldServerName and NewServerName with the entire DNS name of the old server and the new server, such as server1.companyabc.com and server1.companyxyz.com.


Summary

With the advent of technologies such as domain rename and cross-forest trusts, mistakes in Active Directory design have become more forgiving than they were with Windows 2000. However, it is still important to thoroughly examine the political and technical aspects of any organization to design an infrastructure that aligns with its needs. Active Directory is very flexible in these regards and can be matched with the needs of almost any organization. Windows Server 2003 R2 expands upon this design flexibility even further, through the use of tools such as Active Directory Federation Services (ADFS), which allows for ease of administration and user provisioning across AD forests.


Best Practices

  • Fully understand the structure of Active Directory before designing.

  • Secure any external namespace chosen by registering it so that it cannot be used anywhere on the Internet.

  • Start a domain design by considering the single domain model first.

  • Consider using multiple domains for specific reasons only.

  • Consider using the federated forest design model when uniting two disparate Active Directory structures.

  • Control and optimize replication traffic by using sites.

  • Upgrade any down-level clients to reduce administration and maintenance.

  • Use domain rename sparingly, and only when faced with no other alternative.


Chapter 6. Designing Organizational Unit and Group Structure

In This Chapter

  • Defining Organizational Units in Active Directory

  • AD Groups

  • OU and Group Design

  • Starting an OU Design

  • Using OUs to Delegate Administration

  • Group Policies and OU Design

  • Understanding Group Design

  • Sample Design Models

The organization of users, computers, and other objects within the Windows Server 2003 Active Directory (AD) structure gives administrators great flexibility and control over their environments. Both organizational unit (OU) and group structure design can be tailored to fit virtually any business need. There is, however, a great bit of confusion among administrators in the design and use of OUs and groups. Often, OUs are indiscriminately used without reason, and group structure is ineffectual and confusing. With the proper preparation and advance knowledge of their use, however, a functional OU and group design can do wonders to simplify a Windows Server 2003 Active Directory environment.

In addition to the lessons learned from OU and group use in Windows 2000, Windows Server 2003 introduces several functional advantages and improvements to OU and group structure and replication that fundamentally change their design method. Universal Group Membership caching, incremental group replication, and other enhancements have increased the flexibility of OU and group design, and have given administrators greater tools to work with.

This chapter defines organizational units and groups within Windows Server 2003's Active Directory and describes methods of integrating them into various Active Directory designs. Specific step-by-step instructions and "best practice" design advice are given as well. In addition, functional OU and group design models are detailed and compared.


Defining Organizational Units in Active Directory

An organizational unit is an administrative-level container, depicted in Figure 6.1, that is used to logically organize objects in Active Directory. The concept of the organizational unit is derived from the Lightweight Directory Access Protocol (LDAP) standard upon which Active Directory was built, although there are some conceptual differences between pure LDAP and Active Directory.

Figure 6.1. Active Directory organizational structure.

Objects within Active Directory can be logically placed into OUs as defined by the administrator. Although all user objects are placed in the Users container by default and computer objects are placed in the Computers container, they can be moved at any time.

Note

The default Users and Computers folders in Active Directory are not technically organizational units. Rather, they are technically defined as Container class objects. It is important to understand this point because these Container class objects do not behave in the same way as organizational units. To be able to properly utilize services such as Group Policies, which depend on the functionality of OUs, it is recommended that you move your user and computer objects from their default container locations into an OU structure.

Each object in the Active Directory structure can be referenced via LDAP queries that point to its specific location in the OU structure. You will often see objects referenced in this format when you're writing scripts to modify or create users in Active Directory or simply running LDAP queries against Active Directory. For example, in Figure 6.2, a user named Andrew Abbate in the San Jose Users OU would be represented by the following LDAP string:

CN=Andrew Abbate,OU=Users,OU=San Jose,DC=companyabc,DC=com

Figure 6.2. Viewing the LDAP of a user object in AD.

Note

OU structure can be nested, or include sub-OUs that are many layers deep. Keep in mind, however, that the more complex the OU structure, the more difficult it becomes to administer and the more time-consuming directory queries become. Microsoft recommends not nesting more than 10 layers deep. However, it would be wise to keep the complexity significantly shorter than that number to maintain the responsiveness of directory queries.

OUs primarily satisfy the need to delegate administration to separate groups of administrators. Although there are other possibilities for the use of OUs, this type of administration delegation is, in reality, the primary factor that exists for the creation of OUs in an AD environment. See the "Starting an OU Design" section of this chapter for more details on this concept.

The Need for Organizational Units

While there is a tendency to use organizational units to structure the design of Active Directory, OUs should not be created to just document the organizational chart of the company. The fact that the organization has a Sales department, a Manufacturing department, and a Marketing department doesn't suggest that there should be these three Active Directory OUs. An administrator should create organizational units if the departments will be administered separately and/or policies will be applied differently to the various departments. However, if the departments will all be administered by the same IT team, and the policies being applied will also be the same, having multiple OUs is not necessary.

Additionally, organizational units are not exposed to the directory, meaning that if a user wants to send an email to the members of an OU, he would not see the OU structure nor the members in the OU grouping.

To see members of an organizational structure, Active Directory groups should be created. Groups are exposed to the directory and will be seen when a user wants to list members and groups in the organization.


AD Groups

The idea of groups has been around in the Microsoft world for much longer than OUs have been. As with the OU concept, groups serve to logically organize users into an easily identifiable structure. However, there are some major differences in the way that groups function as opposed to OUs. Among these differences are the following:

  • Group membership is viewable by users Whereas OU visibility is restricted to administrators using special administrative tools, groups can be viewed by all users engaged in domain activities. For example, users who are setting security on a local share can apply permissions to security groups that have been set up on the domain level.

  • Membership in multiple groups OUs are similar to a filesystem's folder structure. In other words, a file can reside in only one folder or OU at a time. Group membership, however, is not exclusive. A user can become a member of any one of a number of groups, and her membership in that group can be changed at any time.

  • Groups as security principals Each security group in Active Directory has a unique Security ID (SID) associated with it upon creation. OUs do not have associated Access Control Entries (ACEs) and consequently cannot be applied to object-level security. This is one of the most significant differences because security groups allow users to grant or deny security access to resources based on group membership. Note, however, that the exception to this is distribution groups, which are not used for security.

  • Mail-enabled group functionality Through distribution groups and (with the latest version of Microsoft Exchange) mail-enabled security groups, users can send a single email to a group and have that email distributed to all the members of that group. The groups themselves become distribution lists, while at the same time being available for security-based applications. This concept is elaborated further in the "Distribution Group Design" section later in this chapter.

Group Types: Security or Distribution

Groups in a Windows Server 2003 come in two flavors: security and distribution. In addition, groups can be organized into different scopes: machine local, domain local, global, and universal.

Security Groups

The type of group that administrators are most familiar with is the security group. This type of group is used to apply permissions to resources en masse so that large groups of users can be administered more easily. Security groups can be established for each department in an organization. For example, users in the Marketing department can be given membership in a Marketing security group, as shown in Figure 6.3. This group is then allowed to have permissions on specific directories in the environment.

Figure 6.3. Security group permission sharing.

This concept should be familiar to anyone who is used to administering down-level Windows networks such as NT or Windows 2000. As you will soon see, however, some fundamental changes in Windows Server 2003 change the way that these groups function.

As previously mentioned, security groups have a unique Security ID (SID) associated with them, much in the same way that individual users in Active Directory have an SID. The uniqueness of the SID is utilized to apply security to objects and resources in the domain. This concept also explains why you cannot simply delete and rename a group to have the same permissions that the old group previously maintained.

Distribution Groups

The concept of distribution groups in Windows Server 2003 was introduced in Windows 2000 along with its implementation of Active Directory. Essentially, a distribution group is a group whose members are able to receive Simple Mail Transfer Protocol (SMTP) mail messages that are sent to the group. Any application that can use Active Directory for address book lookups (essentially LDAP lookups) can utilize this functionality in Windows Server 2003.

Distribution groups are often confused with mail-enabled groups, a concept in environments with Exchange 2000/2003. In addition, in most cases distribution groups are not utilized in environments without Exchange 2000/2003 because their functionality is limited to infrastructures that can support them.

Note

In Active Directory, distribution groups can be used to create email distribution lists that cannot be used to apply security. However, if separation of security and email functionality is not required, you can make security groups mail-enabled.

Mail-Enabled Groups

Members of Active Directory groups can be easily sent emails through the concept of mail-enabled groups. These groups are essentially security groups that are referenced by an email address, and can be used to send SMTP messages to the members of the group. This type of functionality becomes possible only with the inclusion of Exchange 2000 or higher. Exchange 2000/2003 actually extends the forest schema to allow for Exchange-related information, such as SMTP addresses, to be associated with each group.

Most organizations will find that mail-enabled security groups satisfy most of their needs, both security-wise and emailwise. For example, a single group called Marketing that contains all users in that department could also be mail-enabled to allow Exchange users to send emails to everyone in the department.

Group Scope

There are four primary scopes of groups in Active Directory. Each scope is used for different purposes, but all simply serve to ease administration and provide a way to view or perform functions on large groups of users at a time. The group scopes are as follows:

  • Machine local groups

  • Domain local groups

  • Global groups

  • Universal groups

Group scope can become one of the most confusing aspects of Active Directory, and it can often require a doctorate degree in Applied BioGroupology to sort it all out. However, if certain design criteria are applied to group membership and creation, the concept becomes more palatable.

Machine Local Groups

Machine local groups are essentially groups that are built into the operating system and can be applied only to objects local to the machine in which they exist. In other words, they are the default local groups such as Power Users, Administrators, and the like created on a standalone system. Before networking simplified administration, local groups were used to control access to the resources on a server. The downside to this approach was that users needed to have a separate user account on each machine that they wanted to access. In a domain environment, using these groups for permissions is not recommended because the administrative overhead would be overwhelming.

Note

Domain controllers in an Active Directory forest do not contain local groups. When the dcpromo command is run on a server to promote it to a domain controller, all local groups and accounts are deleted in favor of domain accounts. Essentially, the local groups and users are replaced with a copy of the domain groups and users. Any special permissions using local users must be reapplied using domain accounts.

Domain Local Groups

Domain local groups, a term that may seem contradictory at first, are domain-level groups that can be used to establish permissions on resources in the domain in which they reside. Essentially, domain local groups are the evolution of the old Windows NT local groups.

Domain local groups can contain members from anywhere in an Active Directory forest or any trusted domain outside the forest. A domain local group can contain members from any of the following:

  • Global groups

  • User accounts

  • Universal groups (in AD Native mode only)

  • Other domain local groups (nested, in Native mode only)

Domain local groups are primarily used for access to resources because different domain local groups are created for each resource and then other accounts and/or groups are added to them. This helps to readily determine which users and groups have access to a resource.

Global Groups

Global groups are the reincarnation of the NT global group, but with slightly different characteristics. These groups can contain the following types of objects:

  • User accounts

  • Global groups from their own domain (Native mode only)

Global groups are primarily useful in sorting users into easily identifiable groupings and using them to apply permissions to resources. What separates global groups from universal groups, however, is that global groups stop their membership replication at the domain boundary, limiting replication outside the domain.

Universal Groups

The concept of universal groups was new with the release of Windows 2000 and has become even more useful in Windows Server 2003. Universal groups are just thatuniversal. They can contain objects from any trusted domain and can be used to apply permissions to any resource in the domain.

Universal groups are available only in Windows Server 2003 or Windows Native 2000 domain functional modes and cannot be used in the Windows Server 2003 Interim or Windows 2000 Mixed mode. This is because Windows NT4 backup domain controllers (BDCs) cannot replicate the functionality present in universal groups.

Although simply making all groups within a domain into universal groups may seem practical, the limiting factor has always been that membership in universal groups is replicated across the entire forest. To make matters worse, Windows 2000 Active Directory universal group objects contained a single multi-entry attribute that defined membership. This meant that any time membership was changed in a universal group, the entire group membership was re-replicated across the forest. Consequently, universal groups were limited in functionality.

Windows Server 2003 introduces the concept of incremental universal group membership replication, which accomplishes replication of membership in universal groups on a member-by-member basis. This drastically reduces the replication effects that universal groups have on an environment and makes the concept of universal groups more feasible for distributed environments. This functionality is not present, however, until the domain has been upgraded to Windows Server 2003 functional level.


OU and Group Design

Understanding the concepts used with Windows Server 2003 design is only part of the battle. The application of those concepts into a best-practice design is the tricky part. You can take heart in the fact that of all the design elements in Active Directory, OU and group structure is the most flexible and forgiving. You could theoretically completely revamp your entire OU structure in the middle of the day without affecting users of the network as OU structure is administrative in function and does not directly affect user operations. That said, care should be taken to ensure that group policies that might be in place on OUs are moved in before user or computer accounts move. Not taking this into account can lead to the application of unwanted group policies to various computer or user objects, often with adverse effects. Group membership is also readily changeable, although thought should be given to the deletion of security groups that are already in use.

Note

Because each group SID is unique, you must take care not to simply delete and re-create groups as you go. As with user accounts, even if you give a new group the same name as a deleted group and add the same users into it, permissions set on the old group will not be applied to the new group.

While keeping these factors in mind and after successfully completing your forest and domain design (see Chapters 4, "Active Directory Primer," and 5, "Designing a Windows Server 2003 Active Directory"), it's now time to start designing an OU and group structure.


Starting an OU Design

As with Active Directory domain design, OU design should be kept simple and expanded only if a specific need makes the creation of an OU necessary. As you will see, compelling reasons for creation of OUs are generally limited to delegation of administration, in most cases.

As with domain design, it is important to establish a frame of reference and common design criteria when beginning design of the OU structure. Organizational units are often graphically represented by a folder that looks like the icon in Figure 6.4.

Figure 6.4. Folder icon in Active Directory.

Another common method of displaying OU structure is represented by simple text hierarchy, as shown in Figure 6.5.

Figure 6.5. Simple text hierarchy for an OU structure.

Whichever way is chosen, it is important to establish a standard method of illustrating the OU design chosen for an organization.

The first step in the design process is to determine the best method of organizing users, computers, and other domain objects within an OU structure. It is, in a way, too easy to create organizational units, and often domain designers create a complex structure of nested OUs, with three or more for every department. Although this approach will work, the truth of the matter is that it gives no technical advantages, and instead complicates LDAP directory queries and requires a large amount of administrative overhead. Consequently, it is better to start an OU design with a single OU and expand the number of OUs only if absolutely necessary.

Mapping the OU Design to an NT Resource Domain Layout

OUs in Active Directory can essentially serve as a replacement for NT resource domains. In a nutshell, this factor alone could make it easier to redesign your network environment. For example, consider the fictional company, CompanyABC, whose NT environment was composed of numerous NT resource domains similar to those shown in Figure 6.6. Each domain is administered by a local IT team.

Figure 6.6. Multiple resource domains in Windows NT4.

When migrating to Windows Server 2003, CompanyABC discovered the administrative advantages to organizational units, as shown in Figure 6.7, and restructured its environment with a single domain to take the place of the NT resource domains that previously existed.

Figure 6.7. Windows Server 2003 single domain with multiple organizational units.

The original purpose of resource domains in NT 4.0 was to separate groups of domain administrators from having control over each other's environment. This, in addition to replication concerns, is what caused so many IT environments to administer an enormous quantity of NT domains. Active Directory allows for these domains to be collapsed into an equivalent OU structure, while allowing for a much greater amount of control for the central IT structure.

Overuse of OUs in Domain Design

Administrators have heard conflicting reports for years about the use of organizational units in Active Directory. Books and resource guides and pure conjecture have fueled the confusion and befuddled many administrators over best practice for their OU structure.

The basic truth about OUs, however, is that you more than likely do not need as many as you think that you need. Add an OU to a domain if a completely separate group needs special administrative access to a segment of users. If this condition does not exist, and a single group of people administers the entire environment, there is often no need to create more than one OU.

This is not to say that there may be other reasons to create OUs. Application of Group Policy, for example, is a potential candidate for OU creation. However, even this type of functionality is better accomplished through other means. It is a little-known fact that Group Policy can be applied to groups of users, thus limiting the need to create an OU for this expressed purpose. For more information on how to accomplish this, see the section "Group Policies and OU Design" later in this chapter.

OU Flexibility

Domain designers are in no way locked in to an OU structure. Users can be moved back and forth between OUs during normal business hours without affecting domain functionality. This fact also helps designers to easily correct any design flaws that may have been made to the OU structure.

OUs were introduced as part of Active Directory with the release of Windows 2000. There are essentially no technical differences between the functionality of OUs in Windows 2000 and the functionality of OUs in Windows Server 2003. However, real-world experience with OU design has changed some of the major design assumptions that were previously made in Windows 2000.


Using OUs to Delegate Administration

As previously mentioned, one of the most important reasons for creating an OU structure in Active Directory is for the purpose of delegating administration to a separate administrator or administrative group. Whereas in NT 4.0 separate domains were necessary for this type of functionality, Active Directory allows for this level of administrative granularity in a single domain. This concept is further illustrated in this section.

Essentially, the role of the NT resource domain has been replaced by the concept of the organizational unit. A group of users can be easily granted specific levels of administrative access to a subset of users. For example, a remote IT group can be granted standard user creation/deletion/password-change privileges to its own OU. The process of delegating this type of access is quite simple and involves the following steps:

1.
In Active Directory Users and Computers, right-click the OU where you want to delegate permissions and choose Delegate Control.

2.
Click Next at the Welcome screen.

3.
Click Add to select the group you want to give access to.

4.
Type in the name of the group and click OK.

5.
Click Next to continue.

6.
Under Delegate the Following Common Tasks, choose the permissions you wantin the example shown in Figure 6.8, Create, Delete, and Manage User Accountsand then click Next.

Figure 6.8. Choosing delegation of common tasks.

7.
Click Finish to finalize the changes.

In fact, the Delegation of Control Wizard allows for an extremely specific degree of administrative granularity. If desired, an administrator can delegate a group of users to be able to modify only phone numbers or similar functionality for users in a specific OU. Custom tasks can be created and enabled on OUs to accomplish this and many other administrative tasks. For the most part, a very large percentage of all the types of administration that could possibly be required for delegation can work in this way. To use the phone administration example, follow these steps to set up custom delegation:

1.
In Active Directory Users and Computers, right-click the OU where you want to delegate permissions and choose Delegate Control.

2.
Click Next at the Welcome screen.

3.
Click Add to select the group to which you want to give access.

4.
Type in the name of the group and click OK.

5.
Click Next to continue.

6.
Select Create a Custom Task to Delegate and click Next.

7.
Under Delegate Control Of, choose Only the Following Objects in the Folder.

8.
Check Users Objects and click Next.

9.
Uncheck the Property-Specific check box.

10.
Under Permissions, check Read and Write Phone and Mail Options, as shown in Figure 6.9, and click Next.

Figure 6.9. Selecting delegate permissions.

11.
Click Finish to finalize the changes.

The possible variations are enormous, but the concept is sound. Active Directory's capability to delegate administrative functionality to this degree of granularity is one of the major advantages inherent in Windows Server 2003.


Group Policies and OU Design

Administrators create group policies to limit users from performing certain tasks or to automatically set up specific functionality. For example, a group policy can be established to display a legal disclosure to all users who attempt to log in to a system, or it can be set up to limit access to the command prompt. Group policies can be set on Active Directory sites, domains, and OUs but can also be configured to apply specifically to groups as well. This functionality increases the domain designer's flexibility to apply group policies.

As previously mentioned in this chapter, creating additional OUs simply to apply multiple group policies is not an efficient use of OU structure and can lead to overuse of OUs in general. Rather, you can achieve a more straightforward approach to group policies by applying them directly to groups of users. The following procedure illustrates how you can apply a specific group policy at the domain level but enact it only on a specific group:

1.
In Active Directory Users and Computers, right-click the domain name and choose Properties.

2.
Select the Group Policy tab.

3.
Select the group policy that you want to apply to a group and click the Properties button.

4.
Select the Security tab.

5.
Uncheck the Read and the Apply Group Policy check boxes from the Authenticated Users Group, if it exists.

6.
Click the Add button to select a group to apply the policy to.

7.
Type the name of the group into the text box and click OK.

8.
Select the group you just added and check the boxes for Read and Apply Group Policy, as shown in Figure 6.10.

Figure 6.10. Adding Read and Apply Group Policy security properties.

9.
Repeat steps 68 for any additional groups to apply the policy.

10.
Click OK and then Close to save the changes.

11.
Repeat steps 110 for any additional group policies.

This concept of applying a specific group policy at the domain level but enacting it at a specific group in and of itself can reduce the number of unnecessary OUs in an environment and help to simplify administration. In addition, group policy enforcement becomes easier to troubleshoot as complex OU structures need not be scrutinized.


Understanding Group Design

As with organizational unit design, it is best to simplify your group structure to avoid unnecessary administrative overhead. Establishing a set policy on how to deal with groups and which groups can be created will help to manage large groups of users more effectively and help troubleshoot security more effectively.

Best Practice for Groups

Group use can be simplified by remembering a simple formula: Use domain local groups to control access to resources and use global groups to organize similar groups of users. When this is done, the global groups created are then applied to the domain local groups as members, allowing those users permissions to those resources and limiting the effect that replication has on an environment.

To illustrate this type of use, consider the example shown in Figure 6.11. Users in the Marketing and Finance departments need access to the same shared printer on the network. Two global groups named Marketing and Finance, respectively, were created and all user accounts from each respective group were added. A single domain local group called Printer1 was created and granted sole access to the shared printer. The Marketing and Finance groups were then added as members of the Printer1 group. This simple formula works on a much larger scale as well and has been found to be best practice for effective use of groups without major replication concerns.

Figure 6.11. Best practice group design example.

The concept of the universal group is also coming of age in Windows Server 2003. Now that the replication issue has been solved through incremental membership replication, it is more likely that this form of group will be possible in an environment. When necessary, a universal group can take the place of global groups or can potentially include global groups as members. Universal groups are most useful in consolidating group membership across domain boundaries, and this should be their primary function if utilized in Windows Server 2003.

Note

Even though universal groups can exist only in Native mode domains, they can theoretically include members from other Mixed mode domains in a forest. This is not recommended, however, because it makes troubleshooting access problems much more difficult. Since members from other domains cannot have an SID of the universal group added to their access token, a Mixed mode domain object is added as a link in a universal group, not as a direct object.

Establishing Group Naming Standards

As with all objects in Active Directory, a group should be easily identifiable so that there is less ambiguity for both end users and administrators. Consequently, it is important to establish some form of naming convention for all groups to have and to communicate those naming conventions to the administrators who will create those groups. Using such conventions will help to alleviate headaches involved with determining what a certain group is used for, who owns it, and similar issues.

Group Nesting

Groups can be nested, or included as members in other groups, to easily add multiple members of known groups as members of other groups. This added flexibility reduces the total number of groups necessary and helps to reduce administrative overhead.

Note

While in Windows 2000 Mixed or Windows Server 2003 Interim modes, like groups cannot be nested. For example, when not in Native mode, a domain local group cannot be nested in another domain local group, and a global group cannot be nested in a separate global group.

Distribution Group Design

If required by your organization, distribution groups can be set up to allow for SMTP mail to be sent to multiple recipients. Bear in mind that these groups do not have SIDs associated with them and consequently cannot be used for security permission assignments. In reality, it is rare that distribution groups will be designed in an organization that is not running Exchange 2000/2003. However, understanding their role and potential is important in determining proper group design.

Note

While still in Mixed or Interim mode with NT BDCs, universal security groups are not available. However, universal distribution groups are available in this mode and can be used to include members from any domain in the forest.


Sample Design Models

Although the possibilities for OU and group design are virtually unlimited, often the same designs unfold because business needs are similar for many organizations. Over time, three distinctive models that influence OU and group design have emerged. The first model is based on a business function design, where varying departments dictate the existence of OUs and groups. The second model is geographical based, where remote sites are granted separate OUs and groups.

Business FunctionBased Design

CompanyA is a clothing manufacturer based in St. Louis, Missouri. Facilities for the company are limited to a small group of locations in Dayton that are connected by T1 lines. A central IT department directly manages approximately 50% of the computer infrastructure within the company. The rest of the company is remotely managed by the following independent groups within the company:

  • Sales

  • Manufacturing

  • Design

  • Management

Historically, there have been five NT domains within the organization, as shown in Figure 6.12. Each domain was created to give each department autonomy and administrative control over its own environment.

Figure 6.12. Multiple Windows NT4 domain structure.

The NT domains were connected via two-way trusts and were named as follows:

  • IT_NT

  • SALES_NT

  • MANUF_NT

  • DESIG_NT

  • MNGMT_NT

OU Design for a Business FunctionBased Design

Although the culture of the company revolves around this decentralized business approach, the IT department wanted to consolidate these domains into a single AD domain, while at the same time preserving the administrative autonomy that the various departments had with the old environment. The result was a single Active Directory domain named companya.com that used five separate OUs, one for each department, similar to the structure shown in Figure 6.13.

Figure 6.13. Organizational unit design.

To create this structure, the resource domains were collapsed into the single AD domain with the use of the Active Directory Migration Tool (ADMTv2). For more detailed analysis of this procedure, see Chapters 16, "Migrating from Windows NT4 to Windows Server 2003," and 17, "Migrating from Windows 2000 to Windows Server 2003."

Administrative rights were assigned to each OU by creating special global groups whose members included the local administrators for each department, as displayed in Figure 6.14. These groups were then delegated password change, user creation/deletion, and other typical administrative capabilities on their respective department's OUs through use of the Delegation of Control Wizard (see the "Using OUs to Delegate Administration" section earlier in this chapter).

Figure 6.14. Delegation control task completion.

Group Design for a Business FunctionBased Design

A group structure was created with five separate global groups that contained users from each department. The global groups were named as follows:

  • IT Global

  • Sales Global

  • Manufacturing Global

  • Design Global

  • Management Global

Resources were assigned domain local groups that followed a standard naming scheme, such as that represented in the following examples:

  • Printer1 DL

  • FileServer3 DL

  • VidConfServer1 DL

  • Printer3 DL

Security rights for all resources were then given to the appropriate domain local groups that were set up. The global groups were added as members to those groups as appropriate. For example, the printer named Printer3 was physically located in an area between both the Design and the Sales departments. It was determined that this printer should be accessible from both groups. Consequently, printing access was given to the Printer3 DL group, and both the Design Global and Sales Global groups were added as members to the Printer3 DL group, as shown in Figure 6.15.

Figure 6.15. Nesting groups to assign permissions.

This type of resource security allowed for the greatest amount of flexibility and reduced the replication of group membership needed in the domain. If, at a later time, the decision is made to allow the IT department to print off Printer3 as well, simply adding the IT Global group into the Printer3 DL group will do the trick. This flexibility is the main goal of this type of design.

Geographical-Based Design

As was the case with the business functionbased design model, domain structures can easily be tailored to the needs of organizations with geographically dispersed locations, each with its own sets of administrators. It is important to understand that simply having sites in remote locations does not immediately warrant creation of an OU for each site. Some type of special local administration is required in those remote sites before OU creation should be considered.

Keeping this point in mind, consider the example of CompanyB. It is an international semiconductor producer that is centralized in Sacramento, California, but has worldwide remote branches in Malaysia, Costa Rica, Tokyo, Australia, Berlin, and Kiev, as shown in Figure 6.16.

Figure 6.16. CompanyB legacy domain structure.

Administration takes place on a continent-by-continent basis. In other words, Berlin and Kiev are both managed by the same team, and Tokyo and Malaysia use the same administrators. Australia administers its own users, as does Costa Rica.

OU Design for a Geographical-Based Design

The AD designers at CompanyB determined that the local administrative requirements of the branch offices were best served through the creation of OUs for each administrative region. A Europe OU was created for users in Berlin and Kiev, and an Asia OU was created for Tokyo and Malaysia. The three other sites were given individual OUs, as shown in Figure 6.17.

Figure 6.17. Redesign using organizational units instead of domains.

Group Design for a Geographical-Based Design

Domain local groups were created to grant access to each OU on a resource basis. For example, a domain local group named Europe OU DL was created for application of security to the Europe organizational unit. To apply this security, the Delegation of Control Wizard was run on each OU, and each corresponding domain local group was granted Administrative access to its own respective OUs.

Membership in the domain local groups was only the first step for allowing CompanyB's administrators to manage their own environments. Global groups were created for each IT team, corresponding with their physical location. For example, Berlin IT Admins Global and Kiev IT Admins Global groups were created, and each IT admin user account for the remote locations was added as a member of its respective groups. The two global groups were then added as members of the Europe OU DL domain local group, as shown in Figure 6.18. The same process was applied to the other OUs in the organization. This solution allowed for the greatest degree of administrative flexibility when dealing with permissions set on the OUs.

Figure 6.18. Nested delegation of control.

Each administrative team was consequently granted a broad range of administrative powers over its own environment, allowing each team to create users, change passwords, and effectively administer its own environments without the need for broad, sweeping administrative powers over the entire domain.

The added advantage of this design is that it is completely flexible, and administrative control can be re-delegated on the fly, so to speak. For example, if a branch office opens in Paris, and IT administrators in that location need to have equivalent administrative control over the Europe OU, a simple global group can be created and added as a member to the Europe OU DL domain local group. Removing permissions is subsequently straightforward. In addition, entire OU memberships can effectively be collapsed into a different OU structure, as required by the changing needs of different organizations.


Summary

Without some form of logical organization of users within your network environment, chaos reigns and administration grinds to a halt. Administrators need some way to lasso groups of users together into logically identifiable groupings so that changes, security privileges, and administration can be accomplished en masse. Active Directory was specifically designed to be extremely scalable in regards to administrative functionality, and the flexibility of OU and group design is a testament to this strength. Proper design of both OU and group structure will go a long way toward helping gain control and reduce overhead in a domain environment.


Best Practices

  • Move your user and computer objects into an OU structure, as opposed to the default Users and Computers containers.

  • Keep the OU structure as simple as possible.

  • Do not nest OUs more than 10 layers deep, and preferably keep them less than 3 layers deep, if possible.

  • Keep the number of OUs to a minimum, and use them only when necessary.

  • Apply Group Policy to members of groups through Group Policy Membership Filtering where possible.

  • Use domain local groups to control access to resources, and use global groups to organize similar groups of users.

  • Use distribution groups or mail-enabled security groups to create email distribution lists in environments with Exchange 2000/2003.

  • Mail-enable security groups if separation of security and email functionality is not required.

  • Don't simply delete and re-create groups on the fly because each group SID is unique.

  • Don't include users from other Mixed mode domains in a forest in universal groups.

  • Don't use local groups for permissions in a domain environment.


Chapter 7. Active Directory Infrastructure

In This Chapter

  • Understanding Active Directory Replication

  • Active Directory Sites

  • Planning Replication Topology

  • Windows Server 2003 IPv6 Support

  • Real-World Replication Designs

In an ideal world, all areas of your network would be connected with high-capacity links, and every server would communicate with each other without latency or congestion. Computers would unite and throw off the bandwidth shackles that tie them down. Alas, no real networks work this way, and traffic concerns must be taken into consideration in all but the smallest, single-server Active Directory (AD) structure. Windows Server 2003 expands upon Active Directory's replication capabilities introduced in Windows 2000 with a range of new features and functionality. Consequently, the introduction of these new capabilities greatly increases the capabilities of Active Directory and also changes some of the fundamental design elements of AD replication.


Understanding Active Directory Replication

Windows Server 2003 improvements in Active Directory replication are directly drawn from lessons learned in Windows 2000. Replication compression can now be disabled in well-connected sites, enabling designers to sacrifice bandwidth for processor utilization in domain controllers (DCs). In addition, novel concepts such as DC Promotion from Media allow global catalog servers to be created from CDs or other media, which greatly increases DC placement flexibility. Improvements such as universal group caching on domain controllers allow remote domain controllers to function as global catalog servers by caching frequently used universal group membership locally. New functionality, such as support for IPv6, has also been added to further improve the operating system.

The redesign of the replication structure in Windows Server 2003 fixes design limitations that have thwarted replication plans in the past. Problems with replication design can potentially cripple a network, and it is therefore wise to put some serious thought into the proper layout and design of an effective replication scheme.

This chapter focuses on the definition of the components of Windows Server 2003's Active Directory that make up its replication topology. It details design strategies for Active Directory sites and provides real-world examples to illustrate the principles behind them. In addition, new components related to AD infrastructure such as support for IPv6 (Internet Protocol version 6) are outlined and described.

Understanding the Role of Replication in Active Directory

All enterprise directory environments must include mechanisms to synchronize and update directory information across the entire directory structure. In Windows Server 2003's Active Directory, this means that every domain controller must be updated with the most recent information so that users can log in, access resources, and interact with the directory accurately.

Active Directory differs from many directory services implementations in that the replication of directory information is accomplished independently from the actual logical directory design. The concept of Active Directory sites is completely independent from the logical structure of Active Directory forests, trees, and domains. In fact, a single site in Active Directory can actually host domain controllers from different domains or different trees within the same forest. This allows for the creation of a replication topology based on a WAN structure, while the directory topology can mirror the organization's structure.

Multimaster Topology Concepts

Active Directory was specifically written to allow for the creation, modification, and deletion of directory information from multiple domain controllers. This concept, known as multimaster replication, allows no one domain controller to be authoritative. If any domain controllers go out of service, any one of the rest of the domain controllers can make changes to directory information. Those changes are then replicated across the domain infrastructure. Of course, there needs to be some level of control on this type of replication so that only the most recent changes take precedence. This type of control is realized in Active Directory through the concept of Update Sequence Numbers (USNs).

Update Sequence Numbers

All enterprise directory services implementations require a mechanism to handle the incremental storage of changes made to directory objects. In other words, whenever a password is changed, that information must be accurately passed to all domain controllers in the domain. This mechanism must also be able to apply only those changes that occurred at the most recent intervals.

Many directory services implementations relied on exact time synchronization on all domain controllers to synchronize information. However, keeping the clocks of multiple servers in sync has been proven to be extremely difficult, and even slight variations in time could affect replication results.

Thus was born the concept of the Update Sequence Number. Active Directory utilizes USNs to provide for accurate application of directory changes. A USN is a 64-bit number that is maintained by each domain controller in Active Directory. The USN is sequentially advanced upon each change that is made to the directory on that specific server. Each additional domain controller also contains a copy of the last-known USN from its peers. Updates are subsequently made to be more straightforward. For example, when requesting a replication update from Server2, Server1 will reference its internal table for the most recent USN that it received from Server2 and request only those changes that were made since that specific number. The simplicity of this design also ensures accuracy of replication across the domain environment.

The integrity of replication is assured with USNs because the USN number is updated only upon confirmation that the change has been written to the specific domain controller. This way, if a server failure interrupts the replication cycle, the server in question will still seek an update based on its USN number, ensuring the integrity of the transaction.

Replication Collisions

The concept of USNs does not completely eliminate the role of proper time synchronization in Active Directory. It is still important to maintain accurate time across a domain environment because of the possibility of replication collisions. A replication collision is an inaccuracy in replicated information that takes place because of changes that are enacted on the same object, but before that change has been replicated to all domain controllers. For example, if an administrator resets a user's password on Server1, and another administrator resets the same user's password on Server2 before Server1 has had a chance to replicate that change, a replication collision will occur. Replication collisions are resolved through the use of property version numbers.

Property Version Numbers

Property version numbers are applied as an attribute to all objects within Active Directory. These numbers are sequentially updated and time-stamped whenever a change is made to that object. If a replication collision occurs, the property version number with the latest time stamp will be enacted, and the older change will be discarded. In the example from the preceding section, the password change with the latest time stamp will be applied to the user.

This concept subsequently requires accurate time synchronization to be a priority for an Active Directory domainalthough it is not as critical as in other directory services implementations that rely on it for all replication activity.

Note

Windows Server 2003 includes a built-in service to synchronize time within a domain. Using the Windows Time Service is recommended to keep DCs synchronized so that they can accurately resolve replication collisions.

Connection Objects

Connection objects are automatically generated by the Active Directory Knowledge Consistency Checker (KCC) to act as pathways for replication communication. They can be manually established, as well, and essentially provide a replication path between one domain controller and another. If, for example, an organization wants to have all replication pushed to a primary domain controller (PDC) before it is disseminated elsewhere, direct connection objects can be established between the two domain controllers.

Creating a connection object is a straightforward process. After one is created, Windows Server 2003 will not attempt to automatically generate a new one across the same route unless that connection object is deleted. To manually set a connection object to replicate between domain controllers, perform the following steps:

1.
Open Active Directory Sites and Services.

2.
Expand Sites\<Sitename>\Servers\<Servername>\NTDS Settings, where Servername is the source server for the connection object.

3.
Right-click NTDS Settings and choose New Active Directory Connection.

4.
Select the target domain controller and click OK.

5.
Name the connection object and click OK.

6.
Right-click the newly created connection object and select Properties to open a properties page similar to Figure 7.1. You can then modify the connection object to fit any specific schedule, transport, and so on.

Figure 7.1. Connection object properties.

Note

The connection objects that appear as automatically generated were created by the KCC component of Active Directory to provide for the most efficient replication pathways. You must therefore have a good reason to manually create these pathways because the automatically generated ones usually do the trick.

Replication Latency

Administrators who are not accustomed to Active Directory's replication topology may become confused when they make a change in AD and find that the change is not replicated immediately across their environment. For example, an administrator may reset a password on a user's account, only to have that user complain that the new password does not immediately work. The reason for these types of discrepancies simply lies in the fact that not all AD changes are replicated immediately. This concept is known as replication latency. Because the overhead required in replicating change information to all domain controllers immediately is large, the default schedule for replication is not as often as may be desired. Replication of critical information can be forced through the following procedure:

1.
Open Active Directory Sites and Services.

2.
Drill down to Sites\<Sitename>\Servers\<Servername>\ NTDS Settings, where Servername is the server that you are connected to and that the desired change should be replicated from.

3.
Right-click each connection object and choose Replicate Now, as shown in Figure 7.2.

Figure 7.2. Forcing replication via connection objects.

[View full size image]

Another useful tool that can be used to force replication is the repadmin command-line tool. This tool is installed as part of the Windows Server 2003 Support Tools on the server media. Once installed, repadmin can be used to force replication for the entire directory, specific portions of the directory, or to sync domain controllers across site boundaries. If the bandwidth is available, a batch file can be effectively written to force replication between domain controllers, effectively making the directory quiescent. Figure 7.3 illustrates an example of a simple batch file that forces the replication of all Active Directory naming contexts between two domain controllers.

Figure 7.3. A sample batch file that forces replication using repadmin.

[View full size image]

In addition to the repadmin utility, the Support Tools install the replmon utility, which allows for a graphic display of replication attempts and history for domain controllers. This utility can be useful for giving advance notice of replication problems before they become major issues. Figure 7.4 illustrates how this utility can display replication information between domain controllers in Active Directory.

Figure 7.4. Monitoring domain controller replication with replmon.

[View full size image]

The default replication schedule can be modified to fit the needs of your organization. For example, you might have very high bandwidth between all your domain controllers in a site and decide to change the default schedule to as low as fifteen minutes. To make this change, perform the following steps:

1.
Open Active Directory Sites and Services.

2.
Drill down to Sites\<Sitename>.

3.
Right-click NTDS Site Settings and choose Properties.

4.
Click Change Schedule.

5.
Set the Schedule to Four Times Per Hour, as shown in Figure 7.5.

Figure 7.5. Setting the default site replication schedule.

[View full size image]

6.
Click OK to save any schedule changes and then OK again to close the NTDS Site Settings Properties page.

Of course, changing this schedule comes with some caveats, namely watching for increased network bandwidth consumption. You should match the trade-off of your organization's needs with the increased resource consumption levels required.

SMTP Versus IP Replication

Active Directory in Windows Server 2003 allows for the dissemination of replication traffic in the form of either IP (RPC) or SMTP packets. This functionality allows for the flexibility to choose SMTP traffic if no direct link exists between two disparate sites in AD.

IP replication traffic is utilized in most cases for intersite communications. This type of traffic uses the familiar Remote Procedure Call (RPC) communications to send information between different sites, making it an ideal form of communications for most WAN-based networks.


Active Directory Sites

The basic unit of Active Directory replication is known as the site. Not to be confused with physical sites or Exchange 5.5 sites, the AD site is simply a group of highly connected domain controllers. Each site is established to more effectively replicate directory information across the network. In a nutshell, domain controllers within a single site will, by default, replicate more often that those that exist in other sites. The concept of the site constitutes the centerpiece of replication design in Active Directory.

Windows Server 2003 Site Improvements

Specific functionality that affects sites has evolved since the days of Windows 2000. Windows Server 2003 introduces numerous replication enhancements that directly affect the functionality of sites and allow for greater design flexibility in regard to site design:

  • GC universal group membership caching

  • Media-based domain controller creation

  • Linked-value replication

  • ISTG algorithm improvements

  • No global catalog full synchronization with schema changes

  • Ability to disable replication packet compression

  • Lingering object detection

These concepts are elaborated more fully in later sections of this chapter.

Associating Subnets with Sites

In most cases, a separate instance of a site in Active Directory physically resides in a separate subnet for other sites. This idea stems from the fact that the site topology most often mimics, or should mimic, the physical network infrastructure of an environment.

In Active Directory, sites are associated with their respective subnets to allow for the intelligent assignment of users to their respective domain controllers. For example, consider the design shown in Figure 7.6.

Figure 7.6. Sample client site assignment.

Server1 and Server2, both members of Site1, are both physically members of the 10.1.1.x subnet. Server3 and Server4 are both members of the 10.1.2.x subnet. Client1, which has a physical IP address of 10.1.2.145, will be automatically assigned Server3 and Server4 as its default domain controllers by Active Directory because the subnets have been assigned to the sites in advance. Making this type of assignment is fairly straightforward. The following procedure details how to associate a subnet with a site:

1.
Open Active Directory Sites and Services.

2.
Drill down to Sites\Subnets.

3.
Right-click Subnets and choose New Subnet.

4.
Enter the network portion of the IP range that the site will encompass. In our example, we use the 10.1.2.0 subnet with a Class C (255.255.255.0) subnet mask.

5.
Select a site to associate with the subnet. In the example shown in Figure 7.7, Site2 was selected.

Figure 7.7. Associating a subnet with a site.

6.
Click OK.

Note

Automatic DC site assignment is built in with Windows 2000 or higher clients. Down-level clients, however, require the use of the Active Directory Client component to utilize this functionality. If the AD Client is not installed, Windows 9x or NT clients may be inadvertently directed to domain controllers in far-away sites.

In addition, it's becoming increasingly important to ensure that clients can properly look up their AD sites because many applications, such as SMS 2003, are site-aware and distribute services based on the location of the client as defined in AD. This makes it critical to include subnet information in AD Sites and Services for all available subnets within an organization.

Using Site Links

By default, the creation of two sites in Active Directory does not automatically create a connection linking the two sites. This type of functionality must be manually created, in the form of a site link.

A site link is essentially a type of connection that joins together two sites and allows for replication traffic to flow from one site to another. Multiple site links can be set up and should normally follow the WAN lines that your organization follows. Multiple site links also assure redundancy so that if one link goes down, replication traffic will follow the second link.

Creation of site links is another straightforward process, although you should establish in advance which type of traffic will be utilized by your site link: SMTP or IP (refer to the section "SMTP Versus IP Replication").

Site link replication schedules can be modified to fit the existing requirements of your organization. If, for example, the WAN link is saturated during the day, a schedule can be established to replicate information at night. This functionality allows you to easily adjust site links to the needs of any WAN link.

With the assumption that a default IP site link is required, the following steps will create a simple site link to connect Site1 to Site2. In addition, the replication schedule will be modified to allow replication traffic to occur only from 6 p.m. to 6 a.m. at one-hour intervals:

1.
Open Active Directory Sites and Services.

2.
Drill down to Sites\Inter-Site Transports\IP.

3.
Right-click IP and choose New Site Link to open a properties page similar to the one in Figure 7.8.

Figure 7.8. Site link creation properties page.

4.
Give a name to the subnet that will easily identify what it is. In our example, we named it Site1 - Site2 SL.

5.
Ensure that the sites you want to connect are located in the Sites in This Site Link box.

6.
Click OK to create the site link.

7.
Right-click the newly created site link and choose Properties.

8.
Click Change Schedule.

9.
Select the appropriate time for replication to occur. In our case, we made replication unavailable from 6 a.m. to 6 p.m. by highlighting the desired hours and choosing the Replication Not Available button, as shown in Figure 7.9.

Figure 7.9. Replication scheduling.

10.
Click OK twice to save all settings to the site link.

Site Link Bridging

By default, all site links are bridged, which means that all domain controllers in every site can communicate directly with any other domain controller through any of a series of site links. Such a bridge has the advantage of introducing redundancy into an environment; for example, if Site A has a link with Site B, and Site B is linked to Site C, servers in Site C can communicate directly with Site A.

On some occasions, it is preferable to turn off this type of replication. For example, your organization may require that certain domain controllers never communicate directly with other domain controllers. In this case, site bridging can be turned off through the following procedure:

1.
Open Active Directory Sites and Services.

2.
Navigate to Sites\Inter-Site Transports\IP (or SMTP, if appropriate).

3.
Right-click the IP (or SMTP) folder and choose Properties.

4.
Uncheck the Bridge All Site Links box, as shown in Figure 7.10.

Figure 7.10. Turning off site link bridging.

5.
Click OK to save the changes.

Note

Turning off site link bridging will effectively make your domain controller replication dependent on the explicit site links you have established.

The Knowledge Consistency Checker and the Intersite Topology Generator

Every domain controller contains a role called the Knowledge Consistency Checker (KCC) that automatically generates the most efficient replication topology at a default interval of every 15 minutes. The KCC creates connection objects that link domain controllers into a common replication topology. The KCC has two components: an intrasite KCC, which deals with replication within the site, and an intersite topology generator (ISTG), which establishes connection objects between sites.

The Windows Server 2003 Replication team vastly improved the algorithm used by the ISTG, which resulted in a several-fold increase in the number of sites that can effectively be managed in Active Directory. The number of sites that can be effectively managed in Active Directory is now 5,000.

Note

Because all domain controllers in a forest must agree on the ISTG algorithm, the improvements to the ISTG are not realized until the schema is updated and all domain controllers are upgraded to Windows Server 2003 (either pre-R2 or R2 levels) and the forest and domain functionality levels are raised to Windows Server 2003 level.

Detailing Site Cost

An AD replication mechanism allows designers and administrators to establish preferred routes for replication to follow. This mechanism is known as site cost, and every site link in Active Directory has a cost associated with it. The concept of site cost, which may be familiar to many administrators, follows a fairly simple formula. The lowest cost site link becomes the preferred site link for communications to a site. Higher cost site links are established mainly for redundancy or to reduce traffic on a specific segment. Figure 7.11 illustrates a sample AD site structure that utilizes different costs on specific site links.

Figure 7.11. Site costs.

To use the example illustrated in Figure 7.11, most traffic between the Sendai and Fukuoka sites follows the Sendai-Tokyo site link because the cost of that site link is 15. However, if there is a problem with that connection or it is saturated, replication traffic will be routed through the Sendai-Morioka and then through the Morioka-Tokyo and Tokyo-Fukuoka site links because the total cost (all site link costs added together) for this route is 17. This type of situation illustrates the advantage of utilizing multiple routes in an Active Directory site topology.

Preferred Site Link Bridgeheads

Often, it becomes necessary to segregate all outgoing or incoming intersite traffic to a single domain controller, thus controlling the flow of traffic and offloading the special processor requirements that are required for this functionality. This concept gave rise to preferred site link bridgeheads, domain controllers in a site that are specifically assigned to be the end or starting point of a site link. The preferred bridgehead servers will subsequently be the handler for all traffic for that specific site link.

Multiple site link bridgeheads can be easily defined in Active Directory. The following example illustrates how this is accomplished. In these steps, Server2 is added as a preferred site link bridgehead for the site link named Site1 - Site2 SL:

1.
Open Active Directory Sites and Services.

2.
Drill down to Sites\<Sitename>\Servers\<Servername>, where Servername is the server you want to establish as a bridgehead server.

3.
Right-click <Servername> and choose Properties to open a properties page similar to Figure 7.12.

Figure 7.12. Defining a preferred bridgehead server.

4.
Select the transport for which this server will be made a bridgehead and choose Add, as illustrated in Figure 7.12.

5.
Click OK to save the settings.

Establishing preferred bridgehead servers can have many advantages. Domain controllers with weaker processors can be excluded from this group, as can domain controllers with Operations Master (OM) roles, especially that of the PDC Emulator, which should never be a bridgehead server, if avoidable. It is important, however, to make sure that at least one server in a site from each naming context is established as a bridgehead server. For example, if you have two domains that occupy space in the same site, you should ensure that at least one domain controller from each domain is established as a preferred bridgehead server to ensure proper domain replication.


Planning Replication Topology

In the ideal world, gigabit cabling runs the entire length of an organization's LAN, encompassing all computers into one big network segment. For those of us who are not so fortunate, network traffic patterns are an important consideration, and a firm understanding of the "pipes" that exist in an organization's network is warranted. If all remote sites are connected by T1 lines, for example, there will be fewer replication concerns than if network traffic passes through a slow link.

With this point in mind, mapping out network topology is one of the first steps in creating a functional and reliable replication topology.

Mapping Site Design into Network Design

Site structure in Windows Server 2003 is completely independent from the domain, tree, and forest structure of the directory. This type of flexibility allows domain designers to structure domain environments without needing to consider replication constrictions. Consequently, domain designers can focus solely on the replication topology when designing their site structure, enabling them to create the most efficient replication environment.

Essentially, a site diagram in Windows Server 2003 should look similar to a WAN diagram of your environment. In fact, site topology in Active Directory was specifically designed to be flexible and adhere to normal WAN traffic and layout. This concept helps to define where to create sites, site links, and preferred site link bridgeheads.

Figure 7.13 illustrates how a sample site structure in AD overlays easily onto a WAN diagram from the same organization. Consequently, it is a very good idea to involve the WAN personnel in a site design discussion. Because WAN environments change in structure as well, WAN personnel will subsequently be more inclined to inform the operating system group of changes that could affect the efficiency of your site design as well.

Figure 7.13. Site and WAN structure.

Establishing Sites

Each "island" of high connectivity should normally be broken into separate sites. This will not only assist in domain controller replication, but will also ensure that clients receive the closest domain controller and global catalog server to themselves.

Note

Windows 2000/XP clients or older versions of Windows using the AD Client utilize DNS to perform site lookups. This means that if your DNS records are inaccurate for a site, clients could be potentially redirected to a domain controller or global catalog server other than the one that is closest to them. Consequently, it is important to ensure that all your sites listed in DNS contain the appropriate server host records. This concept is explained more thoroughly in Chapter 9, "The Domain Name System."

Choosing Between One Site or Many Sites

In some cases, multiple LAN segments may be consolidated into a single site, given that the appropriate bandwidth exists between the two segments. This may be the case for a corporate campus, with various buildings that are associated with LAN "islands" but that are all joined by high-speed backbones. However, there may also be reasons to break these segments into sites themselves. Before the decision is made to consolidate sites or separate into individual sites, all factors must be taken into account.

Single-site design is simpler to configure and administer, but also introduces an increase in inter-segment traffic, as all computers in all buildings must traverse the network for domain authentication, lookups, and the like.

A multiple-site design addresses the problems of the inter-segment traffic because all local client requests are handled by domain controllers or global catalog servers locally. However, the complexity of the environment is more significant and the resources required increase.

Note

It is no longer a firm recommendation that all sites contain at least one global catalog domain controller server. The introduction of the universal group caching capability in Windows Server 2003 can reduce the number of global catalog servers in your environment and significantly reduce the amount of replication activity that occurs. This recommendation still stands, however, for sites with a local Exchange server, because global catalog servers are still critical for this environment.

The requirements of an organization with the resources available should be mapped to determine the best-case scenario for site design. Proper site layout will help to logically organize traffic, increase network responsiveness, and introduce redundancy into an environment.

Associating Subnets with Sites

It is critical to establish the physical boundaries of your AD sites because this information utilizes the most efficient login and directory requests from clients and helps to determine where new domain controllers should be located. Multiple subnets can be associated with a single site, and all potential subnets within an organization should be associated with their respective sites to realize the greatest benefit.

Determining Site Links and Site Link Costs

As previously mentioned, site links should normally be designed to overlay the WAN link structure of an organization. If multiple WAN routes exist throughout an organization, it is wise to establish multiple site links to correspond with those routes.

Organizations with a meshed WAN topology need not establish site links for every connection, however. Logically consolidating the potential traffic routes into a series of pathways is a more effective approach and will help to make your environment easier to understand and troubleshoot.

Site costs should be established by keeping in mind where replication traffic is desired and whether redundant links should be set up. For example, two site links can easily be designated to have equivalent costs so that replication traffic is load-balanced between them, as shown in Figure 7.14.

Figure 7.14. Equivalent site costs on multiple site links.

Choosing Replication Scheduling

Replication traffic can potentially consume all available bandwidth on small or saturated WAN links. By changing the site link replication schedule for off-hours, you can easily force this type of traffic to occur during times when the link is not utilized as heavily. Of course, the drawback to this approach is that changes made on one side of the site link would not be replicated until the replication schedule dictates. Weighing the needs of the WAN with the consistency needs of your directory is therefore important. Throttling the replication schedule is just another tool that can help to achieve these goals.

Choosing SMTP or IP Replication

By default, most connections between sites in Active Directory will utilize IP for replication because the default protocol used, RPC, is more efficient and faster. However, in some cases, it may be wiser to utilize SMTP-based replication. For example, if the physical links on which the replication traffic passes are not always on (or intermittent), SMTP traffic may be more ideal because RPC has a much lower retry threshold. SMTP traffic was designed for environments such as the Internet, where constant retries and resends are necessary to get the message to the destination.

A second common use for SMTP connections is in cases where replication needs to be encrypted so as to cross unsecured physical links, such as the Internet. SMTP can be encrypted through the use of a Certificate Authority (CA) so that an organization that requires replication across an unsecured connection can implement certificate-based encryption.

Encrypting SMTP Site Links

Often, specific portions of an organization may exist across an insecure "no man's land," such as the Internet itself. If your sensitive domain replication information traverses this type of environment, you will either need a highly secure virtual private network (VPN) solution, or you'll need to utilize encrypted SMTP connectors, which allow for replication traffic to be sent across uncontrolled connections, such as those used on the Internet. Obviously, it would be prudent to encrypt this type of traffic through the use of certificates or other SMTP encryption technologies.

To encrypt SMTP intrasite replication, a certificate should first be created and installed to allow the individual SMTP packets to be encrypted. This will help to prevent malicious users from stealing replication information if they happen to intercept the SMTP traffic.

Windows Server 2003 Replication Enhancements

The introduction of Windows 2000 provided a strong replication topology that was adaptive to multiple environments and allowed for efficient, site-based dissemination of directory information. Real-world experience with the product has uncovered several areas in replication that required improvement. Windows Server 2003 addressed these areas by including replication enhancements in Active Directory that can help to increase the value of an organization's investment in AD.

Note

Windows Server 2003 R2 did not introduce significant changes to the AD replication engine, but it does add additional schema objects to Active Directory. Before domain controllers can be updated to R2, the AD schema must first be extended by running the ADPREP /Forestprep command from the R2 CD.

Domain Controller Promotion from Media

An ingenious mechanism is now available in Windows Server 2003 that allows for the creation of a domain controller directly from media such as a burned CD or tape. The upshot of this technique is that it is now possible to remotely build a domain controller or global catalog server across a slow WAN link by shipping the CD to the remote site ahead of time, effectively eliminating the common practice in Windows 2000 of building a domain controller in the central site and then shipping it to a remote site after the fact. This effectively eliminates the need to perform tricks such as building remote GC servers locally and then shipping them to a remote location.

The concept behind the media-based GC/DC replication is straightforward. A current, running domain controller backs up the directory through a normal backup process. The backup files are then copied to a backup media such as a CD or tape and shipped off to the remote GC destination. Upon their arrival, the dcpromo command can be run with the /adv switch (dcpromo /adv), which will activate the option to install from media, as shown in Figure 7.15.

Figure 7.15. DCPromo from media.

After the dcpromo command restores the directory information from the backup, an incremental update of the changes made since the media was created will be performed. Because of this, there still needs to be network connectivity throughout the DCPromo process, although the amount of replication required is significantly less. Because some DCPromo operations across slow WAN links have been known to take days and even weeks, this concept can dramatically help to deploy remote domain controllers.

Note

If the copy of the global catalog that has been backed up is older than the tombstone date for objects in the Active Directory (by default, 60 days from when an object was last validated as being active), this type of DCPromo will fail. This built-in safety mechanism prevents the introduction of lingering objects and also ensures that the information is relatively up to date and no significant incremental replication is required.

Identifying Linked-Value Replication/Universal Group Membership Caching

Previously, all groups in Active Directory had their membership listed as a multivalued attribute. This meant that any time the group membership was changed, the entire group membership needed to be re-replicated across the entire forest. Windows Server 2003 now includes an incremental replication approach to these objects, known as linked-value replication. This approach significantly reduces replication traffic associated with Active Directory.

Directly associated with this concept, Windows Server 2003 allows for the creation of domain controllers that cache universal group membership. This means that it no longer is necessary to place a global catalog server in each site. Any time a user utilizes a universal group, the membership of that group is cached on the local domain controller and is utilized when the next request comes for that group's membership. This also lessens the replication traffic that would occur if a global catalog was placed in remote sites.

One of the main sources of replication traffic was discovered to be group membership querieshence, the focus on fixing this problem. In Windows 2000 Active Directory, every time a client logged in, the client's universal group membership was queried, requiring a global catalog to be contacted. This significantly increased login and query time for clients who did not have local global catalog servers. Consequently, many organizations stipulated that every site, no matter the size, must have a local global catalog server to ensure quick authentication and directory lookups. The downside of this was that replication across the directory was increased because every site received a copy of every item in the entire AD, even though only a small portion of those items was referenced by an average site.

Universal group caching solved this problem because only those groups that are commonly referenced by a site are stored locally, and requests for group replication are limited to the items in the cache. This helps to limit replication and keep domain logins speedy.

Universal group caching capability is established on a per-site basis through the following technique:

1.
Open Active Directory Sites and Services.

2.
Navigate to Sites\<Site Name>.

3.
Right-click NTDS Site Settings and choose Properties.

4.
Check the Enable Universal Group Membership Caching box, as shown in Figure 7.16.

Figure 7.16. Universal group caching.

5.
Click OK to save the changes.

Removing Lingering Objects

Lingering objects, more affectionately known as zombies, are created when a domain controller is down for a period of time that is longer than the tombstone date for the deletion of items. When the domain controller is brought back online, it never receives the tombstone request and those objects always exist on the downed server. These objects could then be re-replicated to other domain controllers, arising from the dead as "zombies." Windows Server 2003 has a mechanism for detecting lingering objects, isolating them and marking them for cleanup.

Disabling Replication Compression

By default, intersite AD replication is compressed so as to reduce the bandwidth consumption required. The drawback to this technique is that extra CPU cycles are required on the domain controllers to properly compress and decompress this data. Windows Server 2003 allows designers the flexibility to turn off this compression, if an organization is short on processor time and long on bandwidth, so to speak.

No Full Synchronization of Global Catalog with Schema Changes

Previously, in Windows 2000, any schema modifications would force a complete resynchronization of the global catalog with all domain controllers across an enterprise. This made it extremely ominous to institute any type of schema modifications because replication modifications would increase significantly following schema modifications. Windows Server 2003 environments do not have this limitation, however, and schema modifications are incrementally updated in the global catalog.

Intersite Topology Generator Algorithm Improvements

The Intersite Topology Generator (ISTG) portion of the KCC has been updated to allow AD environments to scale to site structures of up to 5,000 sites. Previous limitations to the Windows 2000 ISTG essentially kept AD implementations effectively limited to 1,000 sites. This improvement, however, is available only when all servers in your Active Directory environment are Windows Server 2003 systems and the forest functionality levels have been raised to Windows Server 2003 levels.


Windows Server 2003 IPv6 Support

When the original structure of the Internet was taking shape, an addressing scheme was formulated to scale to a large number of hosts. From this thinking came the original design of the Internet Protocol, which included support for 232 addresses. The thinking at the time was that this would be more than enough addresses for all hosts on the Internet. This original design gave birth to the IP address structure that is common today, known as dotted-decimal format (such as 12.155.166.151). At the time, this address space filled the addressing needs of the Internet. However, it was quickly discovered that the range of addresses was inadequate, and stopgap measures such as Network Address Translation (NAT) were required to make more efficient use of the available addresses.

In addition to an inadequate supply of available addresses, the Internet Protocol version 4 (IPv4), as it is known, did not handle routing, IPSec, and QoS support very efficiently. The need for a replacement to IPv4 was evident.

In the early '90s, a new version of the Internet Protocol, known as Internet Protocol version 6 (IPv6), was formulated. This design had several functional advantages to IPv4, namely a much larger pool of addresses from which to choose (2128). This protocol is the future of Internet addressing, and it's vitally important that an operating system support it.

Windows Server 2003 comes with a version of IPv6 ready to install, and is fully supported as part of the operating system. Given the complexity of IPv6, it will undoubtedly take some time before it is adopted widely, but understanding that the support exists is the first step towards deploying it widely.

Defining the Structure of IPv6

To say that IPv6 is complicated is an understatement. Attempting to understand IPv4 has been difficult enough for network engineers; throw in hexadecimal 128-bit addresses and life becomes much more interesting. At a minimum, however, the basics of IPv6 must be understood as future networks will use the protocol more and more as time goes by.

IPv6 was written to solve many of the problems that persist on the modern Internet today. The most notable areas that IPv6 improved upon are the following:

  • Vastly improved address space The differences between the available addresses from IPv4 to IPv6 are literally exponential. Without taking into account loss because of subnetting and other factors, IPv4 could support up to 4,294,967,296 nodes. IPv6, on the other hand, supports up to 340,282,366,920,938,463,463,374,607,431,768, 211,456 nodes. Needless to say, IPv6 authors were thinking ahead and wanted to make sure that they wouldn't run out of space again.

  • Improved network headers The header for IPv6 packets has been streamlined, standardized in size, and optimized. To illustrate, even though the address is four times as long as an IPv4 address, the header is only twice the size. In addition, by having a standardized header size, routers can more efficiently handle IPv6 traffic than they could with IPv4.

  • Native support for auto address configuration In environments where manual addressing of clients is not supported or desired, automatic configuration of IPv6 addresses on clients is natively built into the protocol. This technology is the IPv6 equivalent to the Automatic Private Internet Protocol Addressing (APIPA) feature added to Windows for IPv4 addresses.

  • Integrated support for IPSec and QoS IPv6 contains native support for IPSec encryption technologies and Quality of Service (QoS) network traffic optimization approaches, improving their functionality and expanding their capabilities.

Understanding IPv6 Addressing

An IPv6 address, as previously mentioned, is 128-bits long, as compared to IPv4's 32-bit addresses. The address itself uses hexadecimal format to shorten the nonbinary written form. Take, for example, the following 128-bit IPv6 address written in binary:

111111101000000000000000000000000000000000000000000000000000000000000010000011
00001010011111111111111110010001000111111000111111

The first step in creating the nonbinary form of the address is to divide the number in 16-bit values:

1111111010000000 0000000000000000
0000000000000000 0000000000000000
0000001000001100 0010100111111111
1111111001000100 0111111000111111

Each 16-bit value is then converted to hexadecimal format to produce the IPv6 address:

FE80:0000:0000:0000:020C:29FF:FE44:7E3F

Luckily, the authors of IPv6 included ways of writing IPv6 addresses in shorthand by allowing for the removal of zero values that come before other values. For example, in the address listed previously, the 020C value becomes simply 20C when abbreviated. In addition to this form of shorthand, IPv6 allows continuous fields of zeros to be abbreviated by using a double colon. This can only occur once in an address, but can greatly simplify the overall address. The example used previously then becomes:

FE80:::20C:29FF:FE44:7E3F

Note

It's futile to attempt to memorize IPv6 addresses, and converting hexadecimal to decimal format is often best accomplished via a calculator for most people. This has proven to be one of the disadvantages of IPv6 addressing for many administrators.

IPv6 addresses operate much in the same way as IPv4 addresses, with the larger network nodes indicated by the first string of values and the individual interfaces illustrated by the numbers on the right. By following the same principles as IPv4, a better understanding of IPv6 can be achieved.

Installing IPv6

Windows Server 2003 contains built-in support for IPv6, although it is not installed by default. Installation can take place through the command prompt by simply typing the following command:

Netsh interface ipv6 install

Support can also be added via the Network Components GUI interface by following these steps:

1.
Go to Start, Control Panel.

2.
Double-click Network Connections.

3.
Right-click the LAN adapter to install IPv6 and choose Properties.

4.
Click the Install button.

5.
Select Protocol and then click the Add button.

6.
Select Microsoft TCP/IP version 6, as illustrated in Figure 7.17.

Figure 7.17. Installing IPv6.

7.
Click OK and Close to finalize the installation.

Once installed, the IPv6 address will be configured in addition to the IPv4 address. To display both sets of addresses, type ipconfig /all at the command prompt, as illustrated in Figure 7.18.

Figure 7.18. Viewing IPv4 and IPv6 addresses.

[View full size image]

Migrating to IPv6

The migration to IPv6 has been, and will continue to be, a slow and gradual process. In addition, support for IPv4 during and after a migration must still be considered for a considerable period of time. It is consequently important to understand the tools and techniques available to maintain both IPv4 and IPv6 infrastructure in place during a migration process.

When IPv6 is installed on Windows Server 2003, IPv4 support remains by default. This allows for a period of time in which both protocols are supported. Once migrated completely to IPv6, however, connectivity to IPv4 nodes that exist outside of the network (on the Internet, for example) must still be maintained. This support can be accomplished through the deployment of IPv6 tunneling technologies.

Windows Server 2003 tunneling technology consists of two separate technologies. The first technology, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP), allows for intrasite tunnels to be created between pools of IPv6 connectivity internally in an organization. The second technology is known as 6to4, which provides for automatic intersite tunnels between IPv6 nodes on disparate networks, such as across the Internet. Deploying one or both of these technologies is a must in the initial stages of IPv6 industry adoption.

Making the Leap to IPv6

Understanding a new protocol implementation is not at the top of most people's wish lists. In many cases, improvements such as improved routing, support for IPSec, no NAT requirements, and the like, are not enough to convince organizations to make the change. The process of change is inevitable, however, as the number of available nodes on the IPv4 model decreases. Consequently, it's good to know that Windows Server 2003 is well prepared for the eventual adoption of IPv6.


Real-World Replication Designs

Site topology in Windows Server 2003's Active Directory has been engineered in a way to be adaptable to network environments of all shapes and sizes. Because so many WAN topologies exist, a subsequently large number of site topologies can be designed to match the WAN environment. Despite the variations, several common site topologies are implemented, roughly following the two design models detailed in the following sections. These real-world models detail how the Windows Server 2003 AD site topology can be used effectively.

Hub-and-Spoke Replication Design

CompanyA is a glass manufacturer with a central factory and headquarters located in Leuven, Belgium. Four smaller manufacturing facilities are located in Marseille, Brussels, Amsterdam, and Krakow. WAN traffic follows a typical hub-and-spoke pattern, as diagrammed in Figure 7.19.

Figure 7.19. CompanyA WAN diagram.

CompanyA decided to deploy Windows Server 2003 to all its branch locations and allocated several domain controllers for each location. Sites in Active Directory were designated for each major location within the company and given names to match their physical location. Site links were created to correspond with the WAN link locations, and their replication schedules were closely tied with WAN utilization levels on the links themselves. The result was a Windows Server 2003 Active Directory site diagram that looks similar to Figure 7.20.

Figure 7.20. CompanyA site topology.

Both domain controllers in each site were designated as a preferred bridgehead server to lessen the replication load on the global catalog servers in the remote sites. However, the PDC Emulator in the main site was left off the list of preferred bridgehead servers to lessen the load on that server. Site link bridging was kept activated because there was no specific need to turn off this functionality.

This design left CompanyA with a relatively simple but robust replication model that it could easily modify at a future time as WAN infrastructure changes.

Decentralized Replication Design

CompanyB is a mining and mineral extraction corporation that has central locations in Duluth, Charleston, and Cheyenne. Several branch locations are distributed across the continental United States. Its WAN diagram utilizes multiple WAN links, with various connection speeds, as diagrammed in Figure 7.21.

Figure 7.21. CompanyB WAN diagram.

CompanyB recently implemented Windows Server 2003 Active Directory across its infrastructure. The three main locations consist of five Active Directory domain controllers and two global catalog servers. The smaller sites utilize one or two domain controllers for each site, depending on the size. Each server setup in the remote sites was installed using the Install from Media option because the WAN links were not robust enough to handle the site traffic that a full DCPromo operation would involve.

A site link design scheme, like the one shown in Figure 7.22, was chosen to take into account the multiple routes that the WAN topology provides. This design scheme provides for a degree of redundancy, as well, because replication traffic could continue to succeed even if one of the major WAN links was down.

Figure 7.22. CompanyB site topology.

Each smaller site was designated to cache universal group membership because bandwidth was at a minimum and CompanyB wanted to reduce replication traffic to the lowest levels possible, while keeping user logins and directory access prompt. In addition, traffic on the site links to the smaller sites was scheduled to occur only at hour intervals in the evening so that it did not interfere with regular WAN traffic during business hours.

Each domain controller in the smaller sites was designated as a preferred bridgehead server. In the larger sites, three domain controllers with extra processor capacity were designated as the preferred bridgehead servers for their respective sites to offload the extra processing load from the other domain controllers in those sites.

This design left CompanyB with a robust method of throttling replication traffic to its slower WAN links, but at the same time maintaining a distributed directory service environment that AD provides.


Summary

The separation of the directory model from the replication model in Windows Server 2003's Active Directory allows domain designers to have full flexibility when designing replication topology and enables them to focus on replication efficiency. In addition, several new features in Windows Server 2003, such as IPv6 support, universal group caching, and Install from Media DC promotion, give the replication topology an even greater edge, and allow for the realization of improved replication times and reduced bandwidth.


Best Practices

  • Use the automatically generated connection objects that are created by the KCC, unless a specific reason exists to hard-code replication pathways.

  • Ensure that all your sites listed in DNS contain the appropriate SRV records.

  • Ensure that the schema version has been upgraded to R2 levels before installing Windows Server 2003 R2 on any domain controllers.

  • Use the repadmin and replmon tools to troubleshoot and validate Active Directory replication.

  • Consider using IPv6 for environments consisting of Windows XP and Windows Server 2003 and other IPv6-compliant devices.

  • Use IPv6 tunneling mechanisms such as ISATAP and 6to4 to provide long-term compatibility between IPv4 and IPv6.

  • Install the AD client on down-level 95/98/NT client machines (or replace them) to ensure connection to the closest DC.

  • Don't turn off site link bridging unless you want to make your domain controller replication dependent on the explicit site links that you have established.


Chapter 8. Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories

In This Chapter

  • Understanding and Using Services for Unix 3.5

  • Subsystem for Unix-Based Applications as a Component of Services for Unix

  • Sharing Files Between Unix NFS and Windows

  • Taking Advantage of User Synchronization in SFU

  • Administrative Improvements in Services for Unix

  • Connecting Windows and NetWare Environments with Services for NetWare

  • Microsoft Identity Integration Services 2003

  • Harnessing the Power and Potential of MIIS

  • Working with Active Directory Federation Services

In the past, Microsoft had a bad reputation for giving the impression that its technologies would be the only ones deployed at organizations. The toolsets available to co-exist in cross-platform environments were often weak and were provided mostly as a direct means to migrate from those environments to Microsoft environments. The introduction of Windows Server 2003, however, coincides with the maturation of several new co-existence technologies from Microsoft that allow for tight integration of Microsoft technologies with Unix, Novell, Oracle, and many other environments.

This chapter focuses on three major products: Services for Unix (SFU) 3.5, Services for NetWare (SFNW) 5.03, Microsoft Identity Integration Server (MIIS) 2003, and Active Directory Federation Services. Each one of these products works in combination with Windows Server 2003 technologies to provide for the transparent exchange of information between non-Microsoft and Microsoft environments.

This chapter introduces each environment and describes the various functionality available in each product. In addition, this chapter focuses on the specific integration issues that each product brings to Windows Server 2003 and provides for a high-level understanding of the ways each product can be used to enhance a cross-platform environment.


Understanding and Using Services for Unix 3.5

Microsoft has a long history of not "playing well" with other technologies. With Windows 2003, Microsoft introduced Services for Unix 3.5. With the dawn of Windows Server 2003 R2, Services for Unix (SFU) becomes core to the operating system, showing Microsoft's commitment to interoperability. SFU is now available on the installation CD instead of as a downloadable feature pack, and its integration with Server 2003 R2 is seamless for the first time.

For many years, Unix and Windows systems were viewed as separate, incompatible environments that were physically, technically, and ideologically different. Over the years, however, organizations found that supporting two completely separate topologies within their environments was inefficient and expensive; a great deal of redundant work was also required to maintain multiple sets of user accounts, passwords, environments, and so on.

Slowly, the means to interoperate between these environments was developed. At first, most of the interoperability tools were written to join Unix with Windows, as evidenced by Samba, a method allowing Linux/Unix platforms to access Windows NT file shares. Microsoft's tools always seemed a step behind those available elsewhere. With the release of the new Services for Unix tools in Server 2003 R2 Microsoft leapfrogs traditional solutions, such as Samba, and becomes the leader for cross-platform integration.

Long-awaited functionality such as password synchronization, the capability to run Unix scripts on Windows, joint security credentials, and the like were presented as viable options and can be now be considered as part of a migration to or interoperability scenario with Windows Server 2003.

The Development of Services for Unix

Services for Unix has made large strides in its development. From initial skepticism, the product has developed into a formidable integration and migration utility that allows for a great deal of inter-environment flexibility. The first versions of the software, 1.x and 2.x, were limited in many ways, however. Subsequent updates to the software vastly improved its capabilities and further integrated it with the core operating system.

A watershed development in the development of Services for Unix was the introduction of the 3.0 version of the software. This version enhanced support for Unix through the addition or enhancement of nearly all components. Included with version 3.0 was the Interix product as well, an extension to the POSIX infrastructure of Windows to support Unix scripting and applications natively on a Windows Server.

Then, version 3.5 of SFU WCS released, which included several functionality improvements over SFU 3.0. The following components and improvements have been made in the 3.5 release:

  • Greater support for Windows Server 2003 Active Directory authentication

  • Improved utilities for international language support

  • Threaded application support in Interix

  • Significant Interix performance increases of up to 100%

  • Support for the Volume Shadow Copy Service of Windows Server 2003

Finally, we come to the Server 2003 R2integrated version of SFU. Besides being slip-streamed directly into the operating system, some functional changes have been made. Most importantly, the structure of SFU has changed considerably. Here is the structure of major improvements for the R2 SFU offering:

  • NIS and Active Directory integration with scripts for populating Active Directory from a NIS database

  • Extended NIS interoperability including allowing a Windows Server 2003 R2 system to act as a NIS master in a mixed environment

  • NFS server functionality expanded to Mac OS X and higher clients

  • Subsystem for Unix Applications (SUA) allows a POSIX-compliant Unix application to be run on Windows Server 2003 R2, including many common Unix tools and scripts

  • Easier porting of native Unix and Linux scripts to the SUA environment

The Components of Services for Unix

Services for Unix is composed of several key components, each of which provides a specific integration task with different Unix environments. Any or all of these components can be used as part of Services for Unix as the installation of the suite can be customized, depending on an organization's needs. The major components of SFU are as follows:

  • Subsystem for Unix-based Applications (SUA)

  • Client for NFS

  • Server for NFS

  • Telnet Server

  • Telnet Client

  • Server for NIS

  • Password Synchronization

  • NIS Domains

Each component can be installed separately or multiple components can be installed on a single server as necessary. All components are available from the Add/Remove Window Components Wizard in the Control Panel. Each component is described in more detail in the following sections.

Prerequisites for Services for Unix

Services for Unix R2 interoperates with various flavors of Unix, but was tested and specifically written for use with the following Unix iterations:

  • Sun Solaris 7.x, 8.x, 9.x, or 10

  • Red Hat Linux 8.0 and later

  • Hewlett-Packard HP-UX 11i

  • IBM AIX 5L 5.2

  • Apple Macintosh OS X

Note

SFU is not limited to these versions of Sun Solaris, Red Hat Linux, HP-UX, IBM AIX, and Mac OS X. It actually performs quite well in various other similar versions and implementations of Unix and Linux.

Services for Unix has some other important prerequisites and limitations that must be taken into account before considering it for use in an environment. These factors include the following:

  • Server for NIS must be installed on an Active Directory domain controller. In addition, all domain controllers in the domain must be running Server for NIS.

  • Password synchronization requires installation on domain controllers in each environment.

  • Server for NIS must not be subservient to a Unix NIS Serverit can only be subservient to another Windows-based SFU server. This requirement can be a politically sensitive one and should be broached carefully, as some Unix administrators will be hesitant to make the Windows-based NIS the primary NIS server.

  • The Server for NIS Authentication component must be installed on all domain controllers in the domain in which security credentials will be utilized.

Installing Services for Unix R2

The installation of Services for Unix for Windows Server 2003 R2 is as simple as adding another Windows component. From the Control Panel, go to Add/Remove programs, and then Add/Remove Windows Components. The various parts that make up SFU are all available in their appropriate areas.

Note

You will need your Windows 2003 R2 installation CD to add each of the Services for Unix components.

The installation of Services for Unix is straightforward and uses the familiar Microsoft Add/Remove Windows Components Installation Wizard. After the prerequisites have been satisfied and the desired functionality has been identified.

To install SFU R2, perform the following steps:

1. | Click the Start menu, and select the Control Panel.
2. | Choose Add/Remove Programs.
3. | Choose Add/Remove Windows Components in the left column.
4. | Select Subsystem for Unix-based Applications, and click Next.
5. | You'll be prompted for the location of the CD or another location for the requested files.
6. | The setup will prompt you to download the Utilities and SDK for Unix-based Applications, as shown in Figure 8.1. Click Yes to download the package.
7. | Click Next through the first few screens, and then accept the license agreement.
8. | Enable setuid because this is an important function for many Unix applications. Also choose to set the default behavior to case sensitive if your Unix environment is case sensitive. These options are shown in Figure 8.2.
9. | Click Finish for both screens, and the installation is complete. You will need to reboot for the components to become active.
10. | To install the various Active Directoryrelated components, go to the Add/Remove Windows components menu.
11. | Select Active Directory Services, and then click Details. Select Identity Management for Unix (IDMU), and click Details again to drill down to the IDMU options. Select all three options for a full installation, as shown in Figure 8.3.
12. | Click Next to begin the installation.
13. | You will be prompted to locate the request files on the CD. After installation, click Finish to finish the installation. Finally, reboot for the components to become active.
14. | To install the NFS components, again go to the Add/Remove Windows components menu.
15. | The Microsoft Services for NFS are located under Other Network File and Print Services.
16. | Select Details under Microsoft Services for NFS and choose the appropriate options for your installation (see Figure 8.4).

Figure 8.1. Download the Utilities and SDK for Unix-based Applications.

[View full size image]

Figure 8.2. Reviewing the Utilities and SDK for Unix-based Applications options.

Figure 8.3. Active Directory Services details.

Figure 8.4. Microsoft Services for NFS options.

Note

The Utilities and SDK for Unix-based Applications is fairly large, approximately 180MB. You may download this package in advance to speed up the installation process. There are different packages for x86 and AMD architectures.

Once installed, the various functionalities can be tested in a lab environment or deployed into production.


Subsystem for Unix-Based Applications as a Component of Services for Unix

Administrators familiar with the older versions of Services for Unix will notice one immediate change. Interix has been replaced with the Subsystem for Unix-based Applications. SUA is not an emulation product, and all applications and scripts run natively in the built-in POSIX subsystem of Windows Server 2003.

SUA fills the gap between development on Unix platforms and development in Windows. It was written to allow programmers familiar with Unix to continue to use the most familiar programming tools and scripts, such as grep, tar, cut, awk, vi, and many others. In addition, with limited reprogramming efforts, applications that run on Unix-based systems can be ported over to the Wintel platform, building on the low cost of ownership of Windows while retaining software investments from Unix.

SFU R2 further enhances the capabilities of the Unix subsystem. Performance increases for File I/O, pipe bandwidth, and overall response time have been noticeable, in some cases doubling in speed.

SUA Scripting

Administrators familiar with Unix environments will feel at home working with Interix as both the Korn and C shells are available, and both behave exactly as they would in Unix.

SFU also supports the single-rooted file system through these shells, which negates the need to convert scripts to support drive letters. The single-rooted file system allows for a great deal of functionality, allowing scripts written for Unix to more natively port over to a Windows environment.

SUA Tools and Programming Languages

SUA supports all common Unix tools and utilities, with all the familiar commands such as grep, man, env, pr, nice, ps, kill, and many others. Each tool was built to respond exactly the way it is expected to behave in Unix, as illustrated in Figure 8.5, and Interix users can build or import their own customizable tools using the same procedures that they would in a Unix environment.

Figure 8.5. Using standard Unix commands with the C shell.

[View full size image]


Sharing Files Between Unix NFS and Windows

Services for Unix R2 streamlines the sharing of information between Unix and Windows Server 2003, allowing users from both environments to seamlessly access data from each separate environment, without the need for specialized client software. Utilizing the Server for NFS and NFS Client allows for this level of functionality and provides for a more integrated environment.

Using Server for NFS

Server for NFS acts as a Unix-standard NFS server. It provides disk space from any Windows-based computer on a network to NFS clients, translating their NFS requests to Windows SMB-based requests. No additional client software is necessary, and the Windows Server 2003 server acts and functions like a normal NFS-based Unix server for these clients. This is a great way to bring a standardized share format to a heterogeneous network as Unix and Apple have difficulties using CIFS.

Deploying the NFS Client

The NFS Client component can be installed directly on Windows workstations to allow them to map to NFS exports on a network. The NFS servers can be viewed in the standard Windows Explorer, and no additional software is required on NFS servers. Windows authentication requests are sent to the NFS servers using the UID or GID of a user who is mapped using the User Name Mapping service in SFU. In addition, Unix NFS commands such as net and mount can be used directly from the client.


Taking Advantage of User Synchronization in SFU

The goal of single sign-on, in which users on a network log in once and then have access to multiple resources and environments, is still a long way off. It is common for a regular user to maintain and use three or more separate usernames and associated sets of passwords. Services for Unix goes a long way toward making SSI a reality, however, with the User Name Mapping and Password Synchronization capabilities.

User Name Mapping

User Name Mapping allows specific user accounts in Windows Server 2003 Active Directory to be associated with corresponding Unix user accounts. In addition to mapping identically named user accounts, User Name Mapping allows for the association of user accounts with different names in each organization. This factor is particularly useful considering that Unix user accounts are case sensitive and Windows accounts are not.

User Name Mapping supports the capability to map multiple Windows user accounts to a single user account in Unix. This capability allows, for example, multiple administrators to map Windows Server 2003 Active Directory accounts with the Unix root administrator account.

Synchronizing Passwords with IDMU

Going hand in hand with the User Name Mapping service, Password Synchronization allows for those user accounts that have been mapped to automatically update their passwords between the two environments. This functionality, accessible from the IDMU MMC Console, as illustrated in Figure 8.6, allows users on either side to change their passwords and have the changes reflected on the mapped user accounts in the opposite platform.

Figure 8.6. Adding a Unix server to synchronize with and from.

As previously mentioned, Password Synchronization must be installed on all domain controllers on the Active Directory side because all the DCs must be able to understand the Unix password requests forwarded to them. In addition, Password Synchronization is only supported out of the box in the following Unix platforms:

  • Solaris 7, 8, and 9

  • Red Hat Linux 6.2, 7.0, and 8.0

  • HP-UX 11

All other flavors of Unix require a recompile of the platform, which is made easier by the inclusion of makefiles and SFU source code. SFU R2 also includes the encryption libraries, making it even easier to compile a customized solution.

Adding NIS Users to Active Directory

For users who want their existing NIS servers to continue to provide authentication for Unix and Linux servers, the NIS Migration Wizard is not the best choice. A package of Korn shell scripts downloadable from Microsoft.com makes this process simple. The getusers.ksh script gets a list of all users in a NIS database, including the comment field. This script must be run with an account with the permission to run ypcat passwd. The makeusers.ksh script, which must be run by a user with domain admin privileges, imports these users to Active Directory. The -e flag enables accounts because by default the accounts are created in a disabled state. This is a perfect solution for migrations that require the existing NIS servers to remain intact indefinitely.


Administrative Improvements in Services for Unix

One of the main focuses of Services for Unix R2 was the ability to gain a better measure of centralized control over multiple environments. Tools such as an enhanced Telnet server and client, ActivePerl 5.6 for scripting, and a centralized MMC Admin console make the administration of the Services for Unix components easier than ever. Combined with the improved MMC 3.0 interface, it is easier than ever to manage mixed environments from the Windows platform.

Performing Remote Administration with Telnet Server and Client

Services for Unix uses two distinct and separate Telnet servers. The first, a Windows-based Telnet server, is essentially the same Telnet server that is included in Windows Server 2003 and Windows XP. The second Telnet server is controlled by the SFU inetd component, uses the SUA shell, and must be utilized separately from the Windows Telnet server. Each version of Telnet server supports NT LAN Manager (NTLM) authentication in addition to basic login that supports Unix users.

Scripting with ActivePerl and SFU

In Services for Unix, you can write scripts using the ActivePerl tool, which was fully ported from Unix Perl. Perl scripts can be used in a Windows environment, and ActivePerl directly supports use of the Windows Scripting Host (WSH), which enables Perl scripts to be executed on WSH server systems.


Connecting Windows and NetWare Environments with Services for NetWare

Microsoft has always been very good about offering utilities and services that migrate users off NetWare and onto the Windows network operating system (NOS). Interoperability with NetWare systems was not a high priority. Co-existence has become more streamlined since those days, however, with the development of the Gateway Services for NetWare (GSNW) and Services for NetWare (SFNW) utilities that make interoperability, as well as migration, more straightforward to accomplish.

Gateway Services for NetWare

Integration of a Windows environment with Novell network operating systems is simplified through the use of Gateway Services for NetWare, a robust integration product that allows Windows Server 2003 to integrate and share resources with Novell NetWare. GSNW provides for the following functional elements:

  • Windows Client access to file and print services on NetWare servers

  • NetWare Client service access to Windows file and print servers

Specific scenarios for GSNW include the following:

  • A Windows Server 2003 or Exchange server requires direct access to NetWare file or print services.

    One circumstance in which this service would be required is the extraction of NetWare accounts from a server or the source extraction of accounts from a NetWare-hosted messaging system such as GroupWise.

  • A company is migrating desktop clients from a Novell-based network to a Microsoft Windows Server 2003 network.

    The Microsoft-based clients that have been migrated over and no longer belong to the Novell network but require access to NetWare resources can access the NetWare resources through GSNW.

Note

A Windows server running GSNW can provide only a single gateway to one NetWare server at a time. Multiple simultaneous connections are not supported.

Using Services for NetWare

Services for NetWare (SFNW) 5.02 Service Pack 2 (SP2) provides companies with the tools to integrate or migrate Novell users and resources to Windows environments. SFNW provides the following tools:

  • File and print services for NetWare (FPNW)

  • Microsoft Directory Synchronization Services (MSDSS)

  • File Migration Utility (FMU)

Note

Older versions of Services for NetWare did not support Windows Server 2003. Service Pack 2 for SFNW 5.02 now supports installation on a Windows Server 2003 system.

Installing Services for NetWare 5.03

The installation of SFNW is not without its caveats. First and foremost, MSDSS needs to be installed on a domain controller and the forest schema of Active Directory needs to be extended. Because forest schema changes are not to be taken lightly, this factor alone warrants consideration before the installation procedure. After the schema has been upgraded, the base program can be installed and the latest service pack applied. To install SFNW, perform the following steps:

1. | Download or order SFNW 5.03 and run the MSSDS.MSI package from the media.
2. | If the schema hasn't been updated, a dialog box will appear indicating that the Schema Update Wizard will now start. Click OK to continue.
3. | Click Next at the Welcome screen. Note A schema extension is a very delicate task that affects all domain controllers in a forest and can cause a spike in replication traffic. Make sure you fully understand the implications of an extension on an environment before proceeding.
4. | Setup will inform you that the AD schema will be extended, as illustrated in Figure 8.7. Click OK to extend the schema for MSDSS.
5. | After the schema has been extended, click Finish.
6. | At this point, make sure the schema extension gets replicated across the forest, either naturally or forcibly with the repadmin tool. After the schema extension has propagated, double-click on the msdss.msi package again.
7. | Click Next at the Welcome screen.
8. | Read the license, accept the terms, and click Next to continue.
9. | Select Microsoft Directory Synchronization Services, as illustrated in Figure 8.8, and click Next to continue.
10. | Enter the name and the organization and click Next.
11. | Select Custom Install and click Next.
12. | Select the desired options as illustrated in Figure 8.9 and click Next to continue.
13. | Click Next to begin the installation.
14. | After the installation completes, click Finish and then click Yes when prompted to reboot.

Figure 8.7. Choosing to extend the AD schema for MSDSS.

Figure 8.8. Choosing to install MSDSS.

Figure 8.9. Reviewing installation options for SFNW.

Services for NetWare is now installed and ready for configuration. The applications will be listed under the Administrative Tools menu, as illustrated in Figure 8.10.

Figure 8.10. Finding the Services for NetWare Admin tools.

[View full size image]

File and Print Services for NetWare

File and Print Services for NetWare is a back-end service that allows a Windows server to emulate a NetWare File and Print Server. NetWare clients can connect to the file and printer shares as if they were connecting to a Novell server. Novell clients use the same user interface to access file and printer resources running on an FPNW server. Essentially, FPNW allows an FPNW server to spoof an existing NetWare server after it has been retired, allowing administrators the time to gradually migrate desktops over to the Windows environment.

Specific scenarios for FPNW include the following:

  • A company needs to retire an aging Novell 3.12 server without having to make any network configuration changes to the NetWare desktop clients. The Windows Server 2003 running FPNW would be configured with the same file and print services as the Novell 3.12 server.

  • A company is migrating from a Novell-based network to a Microsoft Windows Server 2003 network. During the migration, Novell-based clients that have not yet been migrated to the Windows Server 2003 network can access the file and print services that have already been migrated over to Windows Server 2003 through FPNW.

Microsoft Directory Synchronization Services

Microsoft Directory Synchronization Services (MSDSS) is a tool used for synchronization of directory information stored in the Active Directory and Novell Directory Services (NDS). MSDSS synchronizes directory information stored in Active Directory with all versions of NetWare; MSDSS supports a two-way synchronization with NDS and a one-way synchronization with Novell 3.x bindery services.

Because Active Directory does not support a container comparable to an NDS root organization and because Active Directory security differs from Novell, MSDSS, in migration mode only, creates a corresponding domain local security group in Active Directory for each NDS organizational unit (OU) and organization. MSDSS then maps each Novell OU or organization to the corresponding Active Directory domain local security group.

MSDSS provides a single point of administration. With a one-way synchronization, changes made to Active Directory will be propagated over to NDS during synchronization. Synchronization from Active Directory to NDS allows changes to object attributes, such as a user's middle name or address, to be propagated. In two-way synchronization mode, changes from NDS to Active Directory require a full synchronization of the object (all attributes of the user object).

One of the key benefits to MSDSS is password synchronization. Passwords can be administered in Active Directory and the changes propagated over to NDS during synchronization. Password synchronization allows users access to Windows Server 2003 and NDS resources with the same logon credentials.

The MSDSS architecture is made up of the following three components. These components manage, map, read, and write changes that occur in Active Directory, NDS, and NetWare bindery services.

  • Session Manager The configuration of the synchronization parameters is handled by this component. For example, you could create separate sessions for different NDS containers that required different synchronization parameters.

  • Object Mapper Relates objects to each other (class, attributes, namespace, rights, and permissions) between the source and target directories.

  • DirSync Provider Changes to each directory are handled by a DirSync (read/write) provider. Light-weight Directory Access Protocol (LDAP) is used for Active Directory calls and NetWare NCP calls for NDS and NetWare binderies.

In addition to the core components of MSDSS, the session configuration settings (session database) are securely stored in Active Directory.

Specific scenarios for MSDSS would include the following:

  • A company is migrating directly from Novell to a Windows Server 2003 network. All network services such as DNS, DHCP, and IIS services are running on a single server. MSDSS can be used to migrate all users and files over to Windows Server 2003 after all services have been migrated.

  • A company is gradually migrating from Novell to a Windows Server 2003 network. The network services such as DNS, DHCP, and IIS are installed on multiple servers and sites. MSDSS can be used to migrate and synchronize AD and NDS directories during the migration.

Migrating Using the File Migration Utility

The File Migration Utility is used to automatically manage the migration of files from NetWare file and print servers to Windows Server 2003 systems.

Integrated with MSDSS, FMU copies files while preserving the permissions and access control lists (ACLs) associated with each file. FMU copies the file permissions using a user-mapping file that matches an NDS user account with an Active Directory account. Through this mapping file created with MSDSS, files and the rights inherited or assigned in NetWare are calculated and maintained in the Windows network, preserving security and minimizing the time-consuming process of reassigning file rights and permissions. Without the mapping file, FMU will assign file permissions on all migrated files to the administrator.

Note

The File Migration Utility will directly map the effective rights of NetWare file folders and files to Windows based on the closest Windows security equivalent. Because NTFS Security does not exactly match with Novell Security, there are some approximations done in this process that should be understood.


Microsoft Identity Integration Server 2003

In many of today's business environments, it is common for many directories to be used to provide authentication for different environments or to provide enterprise-wide address books or contact information. To simplify data synchronization between different applications such as email, phone books, human resources databases, and payroll databases, an organization should use a metadirectory product such as Microsoft Identity Integration Server (MIIS) 2003.

The History of MIIS

MIIS is Microsoft's metadirectory solution. A metadirectory can be considered a master directory that contains the most authoritative directory services data within an organization. In 1996, when the Burton Group (http://www.tbg.com) coined and defined the term, no products existed on the market. Since then, many companies have created their own version of a metadirectory, but each might have its own complicated setup and functionality.

The original version of Microsoft's metadirectory solution was known as Microsoft Metadirectory Services (MMS). This version of the application was effective, but was extremely technical. Many components required customized scripting to function properly, and support for third-party products was minimal.

With the 3.0 release of the product came a change in branding, and Microsoft Identity Integration Server (MIIS) 2003 was born. MIIS introduced more of the metadirectory power that its predecessor possessed, and expanded on the capabilities by introducing built-in Management Agents to provide for synchronization to a wide variety of directories, as listed here:

  • Windows 2000/2003 Active Directory

  • Active Directory in Application Mode (ADAM)

  • Windows NT 4.0

  • Novell NDS and eDirectory

  • SunONE/iPlanet Directory

  • Lotus Notes and Domino

  • Microsoft Exchange 5.5

  • ERP

  • PeopleSoft

  • SAP

  • Microsoft SQL Server

  • dBase

  • Oracle

  • Informix

  • DSMLv2

  • Text files such as LDIF, CSV, delimited, fixed-width, and attribute value pairs

  • Other LDAP-compliant directories

One of the important new features of MIIS 2003 is the capability to allow users to reset their own passwords through a self-service Web page. This frees up a lot of help desk and security time formerly used to reset user passwords, as well as providing a more secure and private method of resetting the passwords.

Presenting the Identity Integration Feature Pack (IIFP)

Realizing the need for a "lite" version of MIIS, Microsoft made available the Identity Integration Feature Pack (IIFP), a free download from Microsoft that allows for metadirectory functionality between Active Directory, Exchange 2000/2003 Global Address List (GAL), and Active Directory in Application Mode (ADAM) forests. This version is as functional as MIIS, except for the fact that it only supports synchronization and provisioning between AD, and not to the other supported directories of MIIS. If you only need to synchronize between two or more AD forests, however, IIFP is perfect for the job. IIFP can be downloaded from one of the links on the MIIS Web site at Microsoft at http://www.microsoft.com/miis.

The SQL Server Database for MIIS

MIIS and the IIFP require the use of a back-end Microsoft SQL Server 2000 database. This database is used to store configuration information and the person-objects stored in the metaverse. The database can be located on a dedicated MIIS server, or it can be on an existing SQL Server box. All of the maintenance and administrative needs of any other SQL database exist for the MIIS databases as well.

MIIS Terminology

Organizations that have many different directories and need to keep information synchronized between these directories need a metadirectory product such as MIIS. MIIS provides a single interface for administrators to access the different directories and to configure how the directories will synchronize and/or replicate with one another, through the metadirectory. Before discussing MIIS any further, an understanding of some key terms is required.

  • Management agent (MA) An MIIS management agent is a tool used to communicate with a specific type of directory. For example, an Active Directory management agent allows for MIIS to import or export data and perform tasks within Microsoft Active Directory.

  • Connected directory (CD) A connected directory is a directory that MIIS communicates with using a configured MA. An example of a connected directory could be a Microsoft Exchange 5.5 directory database.

  • Connector namespace (CS) The connector namespace is the replicated information and container hierarchy extracted from or destined to the respective connected directory.

  • Metaverse namespace (MV) The metaverse namespace is the authoritative directory data created from the information gathered from each of the respective connector namespaces.

  • Metadirectory Within MIIS, the metadirectory is made up of all the connector namespaces plus the authoritative metaverse namespace.

  • Attributes Attributes are the fields of information that are exported from or imported to directory entries. Common directory entry attributes are name, alias, email address, phone number, employee ID, or other information.

MIIS can be used for many tasks but is most commonly used for managing directory entry identity information. The intention here is to manage user accounts by synchronizing attributes such as login ID, first name, last name, telephone number, title, and department. For example, if a user named Jane Doe is promoted and her title is changed from manager to vice president, the title change could first be entered in the HR or Payroll databases, and through MIIS management agents, the change can be replicated to other directories within the organization. This ensures that when someone looks up the title attribute for Jane Doe, it is the same in all the directories synchronized with MIIS. This is a common and basic use of MIIS referred to as identity management. Other common uses of MIIS include account provisioning/deprovisioning, or the automatic centralized creation and deletion of user accounts and group management.

MIIS Management Agents

MIIS 2003 comes with many built-in management agents to simplify an MIIS implementation. These agents are used to configure how MIIS will communicate and interact with the connected directories when the agent is run. The type of management agent chosen depends on what type of directory is being connected.

When a management agent is first created, all the configuration of that agent can be performed during that instance. The elements that can be configured include which type of directory objects will be replicated to the connector namespace, which attributes will be replicated, directory entry join and projection rules, attribute flow rules between the connector namespace and the metaverse namespace, plus more. If a necessary configuration is unknown during the MA creation, it can be revisited and modified later.

Management Agent Run Profiles

After creating a management agent, run profiles must be created to define how the management agent will perform. Options include Full Import, Delta Import, Export Apply Rules, and Full Import and Re-Evaluate Rules. This allows MIIS administrators to give finer administrative privileges to run agents without compromising data integrityfor example, if only an import run profile was created. If you only have to import a profile, the management agent would import the desired directory objects and attributes from the connected directory to the respective connector namespace. The data in the connected directory would never be modified.

Installing Microsoft Identity Integration Server 2003

Installation of MIIS 2003 is straightforward because Service Pack 1 for MIIS eliminated the need to install MIIS on SQL Server 2000 Enterprise edition. Instead, it can be installed on either Standard or Enterprise Edition. To install, perform the following tasks:

1.
Insert the MIIS CD and launch the setup by clicking on Install Microsoft Identity Integration Server 2003, as illustrated in Figure 8.11.

Figure 8.11. Launching MIIS setup.

[View full size image]

2.
At the Welcome screen, click Next to continue.

3.
Read the license agreement and select I Agree. Click Next to continue.

4.
Select Complete Installation and click Next to continue.

5.
Indicate where the SQL Server is located. If it is local, accept the defaults as indicated in Figure 8.12 and click Next to continue.

Figure 8.12. Selecting the SQL Server for MIIS.

6.
Select a service account that MIIS will use and click Next to continue.

7.
Select the Groups that will be created for MIIS as illustrated in Figure 8.13 and click Next to continue.

Figure 8.13. Identifying MIIS Groups.

8.
Click Start to begin the installation.

9.
A security warning dialog box similar to the one shown in Figure 8.14 may appear. If it does, click OK to continue. Security for the service account should be reviewed.

Figure 8.14. An MIIS security warning.

10.
Click Finish when MIIS setup is complete.

At this point, MIIS should be installed and ready for the configuration of management agents, run profiles, and other necessary components for identity management.


Harnessing the Power and Potential of MIIS

MIIS is a very capable and powerful tool. With the right configuration and some fancy scripting, it can be configured to perform an incredible variety of automatic tasks. Today's environments are rife with directories, which increase the amount of administration required to create accounts, delete accounts, and update user information manually. MIIS can greatly ease these requirements, improving administration and security. The next section focuses on some of the most valuable capabilities of MIIS and how to effectively use them.

Managing Identities with MIIS

MIIS can be used for the most basic and easiest configurations. For example, MIIS can be used to synchronize identity information between accounts in different directories. Identity information could include names, email and physical addresses, titles, department affiliations, and much more. Generally speaking, identity information is the type of data commonly found in corporate phone books or intranets. To use MIIS for identity management between Active Directory and an LDAP directory server, follow these high-level steps:

1. | Install MIIS 2003.
2. | Create a management agent for each of the directories, including an Active Directory management agent and an LDAP agent.
3. | Configure the management agents to import directory object types into their respective connector namespaces, as shown in Figure 8.15.
4. | Configure one of the management agentsfor example, the Active Directory MAto project the connector space directory objects and directory hierarchy into the metaverse namespace.
5. | Within each of the management agents, a function can be configured called attribute flow to define which directory object attributes from each directory will be projected into the respective metaverse directory objects. Configure the attribute flow rules for each management agent.
6. | Configure the account-joining properties for directory objects. This is the most crucial step because it will determine how the objects in each directory are related to one another within the metaverse namespace. To configure the account join, certain criteria such as an employee ID or first name and last name combination can be used. The key is to find the most unique combination to avoid problems when two objects with similar names are locatedfor example, if two users named Tom Jones exist in Active Directory.
7. | After completely configuring the MAs and account joins, configure management agent run profiles to tell the management agent what to perform with the connected directory and connector namespace. For example, perform a full import or an export of data. The first time the MA is run, the connected directory information is imported to create the initial connector namespace.
8. | After running the MAs once, they can be run a second time to propagate the authoritative metaverse data to the respective connector namespaces and out to the connected directories.

Figure 8.15. Using the MA Wizard.

[View full size image]

These steps can be used to simplify account maintenance tasks when several directories need to be managed simultaneously. In addition to performing identity management for user accounts, MIIS can also can used to perform management tasks for groups. When a group is projected into the metaverse namespace, the group membership attribute can be replicated out to other connected directories through their management agents. This allows a group membership change to occur in one directory and be replicated to other directories automatically.

Provisioning and Deprovisioning Accounts with MIIS

Account provisioning in MIIS allows advanced configurations of directory management agents, along with special provisioning agents, to be used to automate account creation and deletion in several directories. For example, if a new user account is created in Active Directory, the Active Directory MA could tag this account. Then, when the respective MAs are run for other connected directories, a new user account can be automatically generated in those other accounts.

The provisioning and deprovisioning process in MIIS can be an extremely useful tool in situations where automatic creation and deletion of user accounts is required. For example, a single user account can be created in an HR PeopleSoft database, which can initiate a chain-event of account creations, as illustrated in Figure 8.16.

Figure 8.16. Provisioning accounts with MIIS.

[View full size image]

In addition to creating these accounts, all associated accounts can be automatically deleted through a deprovisioning process in MIIS. By automating this process, administration of the multitude of user accounts in an organization can be simplified and the risk of accidentally leaving a user account enabled after an employee has been terminated can be minimized.

The following high-level example demonstrates the steps required to set up simple account provisioning. In this example, a connected Windows NT domain is connected to MIIS. Any user accounts created in that domain has corresponding Exchange Server 2003 mailboxes created in a separate Active Directory forest.

1. | Install MIIS Enterprise.
2. | Configure a management agent for the connected Windows NT 4.0 Domain.
3. | Configure the NT 4.0 MA so that the attributes necessary to create a resource mailbox flow into the metaverse.
4. | Configure the attribute flow between the NT MA attributes and the MIIS metaverse, as illustrated in Figure 8.17.
5. | Configure an MA for the Active Directory domain in the Exchange Resource forest.
6. | Ensure that the Active Directory MA attributes that MIIS will need to create the mailbox are set similarly to the settings noted in Figure 8.18.
7. | Using Visual Studio .NET 2003, configure a custom Rules Extension DLL to provide for the automatic creation of a mailbox-enabled user account in the resource forest. In this case, the DLL must use the MVExtensionExchange class in the script.
8. | Install this rules extension DLL into the metaverse, as illustrated in Figure 8.19.
9. | Configure Run Profiles to import the information and automatically create the mailboxes.

Figure 8.17. Configuring attribute flow in the NT MA.

[View full size image]

Figure 8.18. Configuring attribute flow in an MA.

[View full size image]

Figure 8.19. Installing a customized rules extension DLL into the metaverse.

[View full size image]

The example described previously, although complex, is useful in situations in which a single Exchange Server 2003 or Exchange 2000 forest is used by multiple organizations. The Security ID (SID) of the NT Domain account is imported into the metaverse and used to create a mailbox in the resource forest that has the external domain account listed as the Associated External Account. Through a centralized MIIS implementation, the Exchange resource forest can support the automatic creation of resource mailboxes for a large number of connected domains.

Summarizing MIIS 2003

MIIS is a versatile and powerful directory synchronization tool that can be used to simplify and automate some directory management tasks. Due to the nature of MIIS, it can also be a very dangerous tool because the management agents can have full access to the connected directories. Misconfiguration of MIIS management agents could result in data loss, so careful planning and extensive lab testing should be performed before MIIS is released to the production directories of any organization. It is often wise to contact certified Microsoft solution providers/partners to help decide whether MIIS is right for your environment, or even to design and facilitate the implementation.


Working with Active Directory Federation Services

Windows Server 2003 R2 introduced Active Directory Federation Services (ADFS). ADFS is a single sign-on solution for web applications, allowing for the authentication of users across multiple directories, such as separate AD forests or Active Directory in Application Mode (ADAM) instances. By managing web-based login identities and tying them together, through Windows login authentication, organizations can more easily manage customer access to web-based applications without compromising internal security infrastructure.

ADFS is managed from an MMC Console, shown in Figure 8.20, that can be installed on a Windows Server 2003 Server R2 Enterprise Edition system.

Figure 8.20. Viewing the ADFS MMC Console.

[View full size image]

ADFS is not a replacement for technologies such as MIIS 2003 and/or the IIFP. Instead of synchronizing identities across various directories, ADFS manages login attempts to web applications made from disparate directories. It is important to understand this concept because ADFS and MIIS perform different roles in an organization's environment.

Understanding the Key Components of ADFS

ADFS is composed of three different server components as follows:

  • Federation Server A Federation server is the main ADFS component, which holds the Federation Service role. These servers route authentication requests between connected directories.

  • Federation Proxy Server A Federation Proxy Server acts as a reverse proxy for ADFS authentication requests. This type of server normally resides in the DMZ of a firewall and is used to protect the back-end ADFS server from direct exposure to the untrusted Internet.

  • Web Server The Web Server component of ADFS hosts the Web Agent component and manages authentication cookies sent to a web server application.

Each of these components can be individually installed in an ADFS structure, or they all can be installed on the same system.

Installing the ADFS with Windows Server 2003 R2

Installing ADFS on a Windows Server 2003 R2 requires several key prerequisites:

  • Windows Server 2003 R2 Enterprise Edition or DataCenter Edition

  • IIS 6.0

  • ASP.NET 2.0

  • .NET Framework 2.0

  • 10MB of free disk space for setup

  • A Secure Sockets Layer (SSL) certificate installed on the default Web site of the server

When the prerequisites have been satisfied and all necessary components, such as ASP.NET 2.0 and IIS 6.0, have been installed, ADFS can be installed via the following process:

1. | Ensure that the prerequisite services, such as IIS and ASP.NET 2.0, have been installed on the server.
2. | Go to Start, Control Panel, Add or Remove Programs.
3. | Click on Add/Remove Windows Components.
4. | Select Active Directory Services by clicking on the text (do not check the box), and click the Details button.
5. | From the list of services, select Active Directory Federation Services by checking the box. Note that by clicking Details you can select which particular components of ADFS, such as the Federation Service Proxy and Web Agents, you want to install on a server. The default is to install only the Web Agents and the Federation Service.
6. | When the dialog box in Figure 8.21 pops up and warns you about the dangers of installing ASP.NET 2.0, click Yes.
7. | When ADFS is selected, as shown in Figure 8.21, click OK to continue.
8. | When prompted to enter the Federation Service information, as shown in Figure 8.22, select the default and click Next to continue.
9. | Click Finish to finalize the installation.

Figure 8.21. Installing ADFS.

[View full size image]

Figure 8.22. Specifying Federation Service information in ADFS.

Working with ADFS

ADFS works by inputting information about connected partners, such as AD forests or ADAM orgs, and inputting specific partner and application information. Each set of information can be inputted by running the various wizards installed by ADFS as follows:

  • Add Resource Partner Wizard This wizard enables you to to manually create or automatically import resource partners by using an XML file. Resource partners contain information about the specific web-based applications that users can access.

  • Add Account Partner Wizard This wizard, shown in Figure 8.23, adds the information about specific account partners, which are connected security token issuers such as domain controllers.

  • Add Applications Wizard This wizard adds specific claims-aware applications to ADFS.

Figure 8.23. Using the Add Account Partner Wizard in ADFS.

[View full size image]

By entering the information about the various web-based applications, and which directories and identities are to be granted access, ADFS can provide for seamless sign-on capabilities among various directories. It can be a valuable asset for an organization that wants to share corporate information with trusted partners, without exposing their valuable internal assets to unnecessary exposure.


Summary

Integration of key Microsoft technology with non-Microsoft environments is no longer an afterthought with the maturation of the three major products detailed in this chapter. Proper utilization of Services for Unix, Services for NetWare, and Microsoft Identity Integration Server 2003 can help to lower the total cost of ownership associated with maintaining multiple platform environments. In addition, these technologies bring closer the lofty ideal of bringing multiple directory environments under a single directory umbrella through the realization of single sign-in, password synchronization, and other key functionality that integrates directories with Windows Server 2003.


Best Practices

  • Use Microsoft Identity Integration Server for identity management and the provisioning of accounts.

  • Be cautious when upgrading the AD schema to support MSDSS with Services for NetWare.

  • Be aware of the differences between NetWare file permissions and NTFS security permissions, and how the File Migration Utility will compensate for those differences.

  • Use Active Directory Federation Services (ADFS) to manage single sign-on web-based applications across multiple AD forests and ADAM implementations.

  • Use the free Identity Integration Feature Pack when you only need to synchronize between AD forests.

  • Only install Server for NIS if the Windows Server is not subservient to any Unix NIS servers.

  • Use the Subsystem for Unix-based Applications to replace legacy Unix scripts and run them in a native Windows environment.

  • Install Server for NIS only on an Active Directory domain controller to enable domain-level authentication from NIS to AD.

  • Install the Client for NFS and Gateway for NFS components on different systems.

  • Install the Server for NIS Authentication component on all domain controllers in the domain in which security credentials will be used.


Part III: Network Services

In This Part

CHAPTER 9 The Domain Name System

CHAPTER 10 DHCP/WINS/Domain Controllers

CHAPTER 11 Internet Information Services v6


Chapter 9. The Domain Name System

In This Chapter

  • Inside the Domain Name System

  • Framework for DNS

  • Getting Started with DNS on Windows Server 2003

  • Understanding Resource Records

  • DNS Zones

  • Zone Transfers

  • DNS Queries

  • Other DNS Components

  • The Evolution of Microsoft DNS

  • DNS Changes in Windows Server 2003

  • DNS in an Active Directory Environment

  • Troubleshooting DNS


Inside the Domain Name System

Name resolution is a key component in any network operating system (NOS) implementation. The capability of any one resource to locate other resources is the centerpiece of a functional network. Consequently, the name-resolution strategy chosen for a particular NOS must be robust and reliable, and it ideally will conform to industry standards.

Windows Server 2003 utilizes the Domain Name System (DNS) as its primary method of name resolution, and DNS is a vital component of any Active Directory implementation. Windows Server 2003's DNS implementation was designed to be compliant with the key Request for Comments (RFCs) that define the nature of how DNS should function. This makes it particularly beneficial for existing network implementations, as it allows Windows Server 2003 to interoperate with other types of RFC-compliant DNS implementations.

This chapter details the key components of DNS in general and provides an overview of Windows Server 2003's specific implementation of DNS. A particular emphasis is placed on the role of DNS in Active Directory and the way it fits in standard and nonstandard configurations. Step-by-step instructions outline how to install and configure specific DNS components on Windows Server 2003. In addition, troubleshooting DNS issues and specific Active Directory design scenarios help to give a hands-on approach to your understanding of DNS.

The Need for DNS

Computers and humans conceptualize in drastically different ways. In terms of understanding locations, humans are much better at grasping the concept of names rather than numbers. For example, most people think of cities by their names, not by their ZIP Codes. Computers, however, work in binary, and subsequently prefer to work with numbers. For example, computers at the post office translate the city and address names into specific ZIP Codes for that region, helping each letter reach its destination.

Name resolution for computer systems works in a similar way. A user-friendly name is translated into a computer-identifiable number. TCP/IP uses a number scheme that uniquely identifies each computer interface on a network by a series of numbers, such as 10.1.2.145, known as an IP address. Because most humans are not interested in memorizing several of these types of numbers, they must be easily resolvable into user-friendly names such as www.microsoft.com.

DNS, in its simplest form, provides for name resolution in a distributed fashion, with each server or set of servers controlling a specified zone and with entries for each resource called resource records (RRs) that indicate the location of a particular object.

A good analogy for DNS can be found in telephone books. Each city or metropolitan area (namespace) publishes a separate phone book (zone) that contains many listings (resource records) that map people's names to their phone numbers (IP addresses). This simple example illustrates the basic principle behind DNS. When you understand these basics, further drilling down into the specifics, especially with regard to Windows Server 2003's DNS, is possible.

DNS History

The Internet, as originally implemented, utilized a simple text file called a HOSTS file that contained a simple list of all servers on the Internet and their corresponding IP addresses. This file was copied manually from the master server to multiple secondary HOSTS servers. As more and more servers were added to the Internet, however, updating this file become unmanageable, and a new system became necessary.

In 1983, in direct response to this problem, the RFCs for the Domain Name System were drawn up, and this form of name resolution was implemented on a large scale across the Internet. Instead of a small number of static HOSTS files, DNS servers formed a hierarchical method of name resolution, in which servers resolved only a certain segment of hosts on the Internet and delegated requests that it did not manage. This allowed the number of records held in DNS to scale enormously, without a subsequent large performance decrease.

Microsoft developed its own implementation of DNS in Windows NT 4.0, which was based on the RFC standards on which DNS was founded. With the introduction of Windows 2000, Microsoft adopted DNS as the name-resolution strategy for Microsoft products. Older, legacy name-resolution systems such as WINS are slowly being phased out. Since that time, the DNS implementation used by Microsoft has evolved to include a number of key benefits that distinguish it from standard DNS implementations, such as those in other DNS implementationsfor example, Unix BIND. To understand these improvements, however, you first need a basic understanding of DNS functionality.


Framework for DNS

DNS structure is closely tied to the structure of the Internet and often is confused with the Internet itself. The structure of DNS is highly useful, and the fact that it has thrived for so long is a tribute to its functionality. A closer examination of what constitutes DNS and how it is logically structured is important in understanding the bigger picture of how DNS fits in Windows Server 2003.

DNS Hierarchy

DNS uses a hierarchical approach to name resolution in which resolution is passed up and down a hierarchy of domain names until a particular computer is located. Each level of the hierarchy is divided by dots (.), which symbolize the division. A fully qualified domain name (FQDN) such as server1.sales.companyabc.com uniquely identifies a resource's space in the DNS hierarchy. Figure 9.1 shows how the fictional CompanyABC fits into the DNS hierarchy.

Figure 9.1. DNS hierarchy.

The top of the hierarchy is known as the root, and is represented by a single . (dot) that is managed by the main Internet Registration Authority. Moving down the DNS hierarchy, the next layer in the model is made up of .com, .net, .gov, .fr, and similar domain namespaces that loosely define the particular category that a domain namespace fits into. For example, educational institutions are commonly given .edu extensions, and commercial businesses are given .com extensions. These extensions form the first set of branches to the DNS tree.

The second level in the DNS hierarchy commonly contains the business name of an organization, such as companyabc in Figure 9.1. This level is normally the first area in the DNS hierarchy where an organization has control over the records within the domain and where it can be authoritative.

Subdomains can easily be, and often are, created in the DNS hierarchy for various reasons. For example, sales.microsoft.com is a potential domain that could exist as a sublevel of the microsoft.com domain. The DNS hierarchy works in this way, with multiple levels possible.

The DNS Namespace

The bounded area that is defined by the DNS name is known as the DNS namespace. Microsoft.com is a namespace, as is marketing.companyabc.com. Namespaces can be either public or private. Public namespaces are published on the Internet and are defined by a set of standards. All the .com, .net, .org, and similar namespaces are external, or public. An internal namespace is not published to the Internet, but is also not restricted by extension name. In other words, an internal, unpublished namespace can occupy any conceivable namespace, such as dnsname.local or companyabc.internal. Internal namespaces are most often used with Active Directory because they give increased security to a namespace. Because such namespaces are not published, they cannot be directly accessed from the Internet.


Getting Started with DNS on Windows Server 2003

To fully understand the capabilities that Windows Server 2003 offers for DNS, the product should be installed in a lab environment. This helps to conceptualize the various components of DNS that are presented in this chapter.

Installing DNS Using the Configure Your Server Wizard

Although there are various ways to install and configure DNS, the most straightforward and complete process involves invoking the Configure Your Server Wizard and the subsequent Configure a DNS Server Wizard. The process detailed in this section illustrates the installation of a standard zone. Multiple variations of the installation are possible, but this particular scenario is illustrated to show the basics of DNS installation.

Installation of DNS on Windows Server 2003 is straightforward, and no reboot is necessary. To install and configure the DNS service on a Windows Server 2003 computer, follow these steps. If DNS is already installed on a server but not configured, start the procedure from step 7.

1.
Choose Start, All Programs, Administrative Tools, Configure Your Server Wizard.

2.
Click Next on the Welcome screen.

3.
Make sure that the listed prerequisites have been satisfied and click Next to continue. The Configure Your Server Wizard will then perform a network test.

Note

If running the Configure Your Server Wizard as noted in step 3 with the typical configuration selected, the networking components for DNS and Active Directory Domain Controller will be installed automatically at this point. If you select the custom configuration in the Configure Your Server Wizard, you need to follow steps 4 through 21.

4.
Select the DNS Server Component and click Next.

5.
Verify that the Install DNS Server and Run the Configure a DNS Server Wizard to Configure DNS options are selected and click Next.

6.
After DNS is installed, you may be prompted for your Windows Server 2003 CD. If so, insert it and click OK when prompted.

7.
The Configure a DNS Server Wizard is then started automatically, as illustrated in Figure 9.2. (Or, if DNS is already installed, install it manually by choosing Start, Run, and then typing dnswiz.exe.)

Figure 9.2. The Configure a DNS Server Wizard.

8.
On the Welcome screen for the Configure a DNS Server Wizard, click Next to continue.

9.
Select Create Forward and Reverse Lookup Zones (Recommended for Large Networks) and click Next.

10.
Select Yes, Create a Forward Lookup Zone Now (Recommended) and click Next.

11.
Select the type of zone to be createdin this case, choose Primary Zoneand click Next. If the server is a domain controller, the Store the Zone in Active Directory check box is available.

12.
Type the name of the zone in the Zone Name box and click Next.

13.
At this point, you can create a new zone text file or import one from an existing zone file. In this case, choose Create a New File with This File Name and accept the default. Click Next to continue.

14.
The subsequent screen allows a zone to either accept or decline dynamic updates. In this case, enable dynamic updates by selecting the Allow Both Nonsecure and Secure Dynamic Updates radio button and clicking Next.

Note

When enabling dynamic updates to be accepted by your DNS server, be sure you know the sources of dynamic updated information. If the sources are not reliable, you can potentially receive corrupt or invalid information from a dynamic update.

15.
The next screen allows for the creation of a reverse lookup zone. Here, select Yes, Create a Reverse Lookup Zone Now and click Next.

16.
Select Primary Zone and click Next.

17.
Type in the network ID of the reverse lookup zone and click Next. (The network ID is typically the first set of octets from an IP address in the zone. If a class C IP range of 10.1.1.0/24 is in use on a network, you would enter the values 10.1.1, as illustrated in Figure 9.3.)

Figure 9.3. Reverse lookup zone creation.

18.
Again, you are offered the option to create a new zone file or to utilize an existing file. In this case, choose Create a New File with This File Name and click Next to continue.

19.
Again, you are presented the option for dynamic updates. In this case, select Allow Both Nonsecure and Secure Dynamic Updates and click Next to continue.

20.
The next screen deals with the setup of forwarders, which will be described in more detail in the "DNS Zones" section later in this chapter. In this example, choose No, It Should Not Forward Queries and click Next to continue.

21.
The final window, shown in Figure 9.4, displays a summary of the changes that will be made and the zones that will be added to the DNS database. Click Finish twice to finalize the changes and create the zones.

Figure 9.4. The final steps of the Configure a DNS Server Wizard.

Note

Depending on network connectivity, there may be a pop-up dialog box between the two clicks to finish the DNS changes in step 21. If you are not connected to a LAN, an error dialog box will be displayed regarding searching for root hints. Although the dialog box notes the root hint error, clicking OK will still configure DNS successfully.

Configuring DNS to Point to Itself

DNS is installed immediately upon the closing of the Configure a DNS Server Wizard. One subtask that should be accomplished after the installation is configuring the DNS server in the TCP/IP settings to point to itself for DNS resolution, unless there is a specific reason not to do so. To accomplish this task, perform the following steps:

1. | Choose Start, Control Panel, Network Connections.
2. | While in Network Connections, right-click [Local Area Connection] (where Local Area Connection is the particular network adapter that is to be utilized on the network where DNS is implemented) and select Properties.
3. | Double-click Internet Protocol (TCP/IP).
4. | In the DNS Server boxes, make sure that Use the Following DNS Server Addresses is selected and then type the IP address of the DNS server into the Preferred DNS Server box.
5. | If you have another DNS server, you can enter it into the Alternate DNS Server box.
6. | Click OK twice to complete the changes. Note Previous recommendations for Windows 2000 stipulated that a root DNS server point to another DNS server as the primary name server. This recommendation was made in response to what is known as the "island" problem in Windows DNS. Administrators will take heart in the fact that Windows Server 2003 no longer is subject to this problem, and it is now recommended that you configure a DNS server to point to itself in most cases. You can find more information on this concept later in this chapter.


Understanding Resource Records

In the DNS hierarchy, objects are identified through the use of resource records (RRs). These records are used for basic lookups of users and resources within the specified domain and are unique for the domain in which they are located. Because DNS is not a flat namespace, however, multiple identical RRs can exist at different levels in a DNS hierarchy. The distributed nature of the DNS hierarchy allows such levels.

Several key resource records exist in most DNS implementations, especially in those associated with Windows Server 2003 Active Directory. A general familiarity with these specific types of RRs is required to gain a better understanding of DNS.

Start of Authority Records

The Start of Authority (SOA) record in a DNS database indicates which server is authoritative for that particular zone. The server referenced by the SOA records is subsequently the server that is assumed to be the best source of information about a particular zone and is in charge of processing zone updates. The SOA record contains information such as the Time to Live (TTL) interval, the contact person responsible for DNS, and other critical information, as illustrated in Figure 9.5.

Figure 9.5. A sample SOA record.

An SOA record is automatically created when DNS is installed for Active Directory in Windows Server 2003 and is populated with the default TTL, primary server, and other pertinent information for the zone. After installation, however, these values can be modified to fit the specific needs of an organization.

Host (A) Records

The most common type of RR in DNS is the host record, also known as an A record. This type of RR simply contains the name of the host and its corresponding IP address, as illustrated in Figure 9.6.

Figure 9.6. Sample host records.

[View full size image]

The vast majority of RRs in DNS are A records because they are used to identify the IP addresses of most resources within a domain.

Name Server (NS) Records

Name Server (NS) records identify which computers in a DNS database are the name servers, essentially the DNS servers for a particular zone. Although there can be only one SOA record for a zone, there can be multiple NS records for the zone, which indicate to clients which machines are available to run DNS queries against.

Note

Name Server records, or NS records, do not actually contain the IP information of a particular resource. In fact, in most cases only A records contain this information. NS records and other similar records simply point to a server's A record. For example, an NS record will simply point to server1.companyabc.com, which will then direct the query to the server1 A record in the companyabc.com zone.

Service (SRV) Records

Service (SRV) records are RRs that indicate which resources perform a particular service. Domain controllers in Active Directory are referenced by SRV records that define specific services, such as the global catalog, LDAP, and Kerberos. SRV records are a relatively new addition to DNS, and did not exist in the original implementation of the standard. Each SRV record contains information about a particular functionality that a resource provides. For example, an LDAP server can add an SRV record indicating that it can handle LDAP requests for a particular zone. SRV records can be very useful for Active Directory because domain controllers can advertise that they handle global catalog requests, as illustrated in Figure 9.7.

Figure 9.7. Sample SRV record for an Active Directory global catalog entry.

Note

Because SRV records are a relatively new addition to DNS, they are not supported by several down-level DNS implementations, such as Unix BIND 4.1.x and NT 4.0 DNS. It is therefore critical that the DNS environment that is used for Windows Server 2003's Active Directory have the capability to create SRV records. For Unix BIND servers, version 8.1.2 or higher is required.

Mail Exchanger (MX) Records

A Mail Exchanger (MX) record indicates which resources are available for SMTP mail reception. MX records can be set on a domain basis so that mail sent to a particular domain will be forwarded to the server or servers indicated by the MX record. For example, if an MX record is set for the domain companyabc.com, all mail sent to user@companyabc.com will be automatically directed to the server indicated by the MX record.

Pointer (PTR) Records

Reverse queries to DNS are accomplished through the use of Pointer (PTR) records. In other words, if a user wants to look up the name of a resource that is associated with a specific IP address, he would do a reverse lookup using that IP address. A DNS server would reply using a PTR record that would indicate the name associated with that IP address. PTR records are most commonly found in reverse lookup zones.

Canonical Name (CNAME) Records

A Canonical Name (CNAME) record represents a server alias, or essentially allows any one of a number of servers to be referred to by multiple names in DNS. The record essentially redirects queries made to it to the A record for that particular host. CNAME records are useful when migrating servers and for situations in which friendly names, such as mail.companyabc.com, are required to point to more complex server-naming conventions such as sfoexch01.companyabc.com.

Other Records

Other, less common forms of records that may exist in DNS have specific purposes, and there may be cause to create them. The following is a sample list, but is by no means exhaustive:

  • AAAA Maps a standard IP address into a 128-bit IPv6 address, as indicated in Figure 9.8. This type of record will become more prevalent as IPv6 is adopted.

  • ISDN Maps a specific DNS name to an ISDN telephone number.

  • KEY Stores a public key used for encryption for a particular domain.

  • RP Specifies the Responsible Person for a domain.

  • WKS Designates a particular Well Known Service.

  • MB Indicates which host contains a specific mailbox.

Figure 9.8. AAAA resource record.

Previous Page
Next Page


DNS Zones

A zone in DNS is a portion of a DNS namespace that is controlled by a particular DNS server or group of servers. The zone is the primary delegation mechanism in DNS and is used to establish boundaries over which a particular server can resolve requests. Any server that hosts a particular zone is said to be authoritative for that zone, with the exception of stub zones, which are defined later in the chapter. Figure 9.9 illustrates how different portions of the DNS namespace can be divided into zones, each of which can be hosted on a DNS server or group of servers.

Figure 9.9. DNS zones.

It is important to understand that any section or sub-section of DNS can exist within a single zone. For example, an organization may decide to place an entire namespace of a domain, subdomains, and sub-subdomains into a single zone. Or specific sections of that namespace can be divided up into separate zones. In fact, the entire Internet namespace can be envisioned as a single namespace with . as the root, which is divided into a multitude of different zones.

Note

A server that is installed with DNS but does not have any zones configured is known as a caching-only server. Establishing a caching-only server can be useful in some branch office situations because it can help to alleviate large amounts of client query traffic across the network and eliminate the need to replicate entire DNS zones to remote locations.

Forward Lookup Zones

A forward lookup zone is created to, as the name suggests, forward lookups to the DNS database. In other words, this type of zone resolves names to IP addresses and resource information. For example, if a user wants to reach Server1 and queries for its IP address through a forward lookup zone, DNS returns 10.0.0.11, the IP address for that resource.

Note

There is nothing to stop the assignment of multiple RRs to a single resource. In fact, this practice is common and useful in many situations. It may be practical to have a server respond to more than one name in specific circumstances. This type of functionality is normally accomplished through the creation of CNAME records, which create aliases for a particular resource.

Reverse Lookup Zones

A reverse lookup zone performs the exact opposite operation as a forward lookup zone. IP addresses are matched up with a common name in a reverse lookup zone. This is similar to knowing a phone number but not knowing the name associated with it. Reverse lookup zones must be manually created, and do not always exist in every implementation. Reverse lookup zones are primarily populated with PTR records, which serve to point the reverse lookup query to the appropriate name.

Primary Zones

In traditional (non-Active Directoryintegrated) DNS, a single server serves as the master DNS server for a zone, and all changes made to that particular zone are done on that particular server. A single DNS server can host multiple zones, and can be primary for one and secondary for another. If a zone is primary, however, all requested changes for that particular zone must be done on the server that holds the master copy of the zone.

Creating a new primary zone manually is a fairly straightforward process. The following procedure outlines the creation of a standard zone for the companyabc.com DNS namespace:

1. | Open the DNS MMC snap-in (Start, Administrative Tools, DNS).
2. | Navigate to DNS\<Servername>\Forward Lookup Zones.
3. | Right-click Forward Lookup Zones and choose New Zone.
4. | Click Next on the Welcome screen.
5. | Select Primary Zone from the list of zone types available. Because this zone will not be AD integrated, uncheck Store the Zone in Active Directory if it is unchecked and then click Next to continue.
6. | Type in the name of the primary zone to be created and click Next.
7. | Because a new zone file will be created as opposed to importing an existing zone file, select Create a New File With This File Name and click Next.
8. | Determine whether dynamic updates will be allowed in this zone. If not, select Do Not Allow Dynamic Updates and click Next to continue.
9. | Click Finish on the Summary page to create the zone.

Secondary Zones

A secondary zone is established to provide redundancy and load balancing for the primary zone. Each copy of the DNS database is read-only, however, because all recordkeeping is done on the primary zone copy. A single DNS server can contain several zones that are primary and several that are secondary. The zone creation process is similar to the one outlined in the preceding section on primary zones, but with the difference being that the zone is transferred from an existing primary server.

Stub Zones

The concept of stub zones is new in Microsoft DNS. A stub zone is essentially a zone that contains no information about the members in a domain but simply serves to forward queries to a list of designated name servers for different domains. A stub zone subsequently contains only NS, SOA, and glue records. Glue records are essentially A records that work in conjunction with a particular NS record to resolve the IP address of a particular name server. A server that hosts a stub zone for a namespace is not authoritative for that zone.

As illustrated in Figure 9.10, the stub zone effectively serves as a placeholder for a zone that is authoritative on another server. It allows a server to forward queries that are made to a specific zone to the list of name servers in that zone.

Figure 9.10. Stub zones.

[View full size image]

You can easily create a stub zone in Windows Server 2003 after the need has been established for this particular type of functionality. The following procedure details the steps involved with the creation of a stub zone:

1.
Open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.
Navigate to DNS\<Servername>\Forward Lookup Zones.

3.
Right-click Forward Lookup Zones and choose New Zone.

4.
Click Next on the Welcome screen.

5.
Select Stub Zone from the list of zone types. Because this zone will not be AD integrated, uncheck Store The Zone In Active Directory if it is unchecked and then click Next to continue.

6.
Type in the name of the zone that will be created and click Next to continue.

7.
Select Create a New File With This File Name and accept the defaults, unless migrating from an existing zone file. Then click Next to continue.

8.
Type in the IP address of the server or servers from which the zone records will be copied. Click Add for each server entered, as shown in Figure 9.11, and then click Next to continue.

Figure 9.11. A newly created stub zone.

9.
Click Finish on the Summary page to create the zone.

The newly created stub zone will hold only the SOA, NS, and glue records for the domain at which it is pointed.


Zone Transfers

Copying the DNS database from one server to another is accomplished through a process known as a zone transfer. Zone transfers are required for any zone that has more than one name server responsible for the contents of that zone. The mechanism for zone transfers varies, however, depending on the version of DNS and whether the zone is Active Directoryintegrated.

DNS servers can be configured to notify other DNS servers of changes to a zone and begin a zone transfer on a scheduled basis. To set up a server to send zone transfers to another server from a forward lookup zone, follow this procedure:

1.
Open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.
Navigate to DNS\<Servername>\Forward Lookup Zones.

3.
Right-click the name of the zone and choose Properties.

4.
Choose the Zone Transfers tab.

5.
Check Allow Zone Transfers and select Only To The Following Servers.

6.
Type in the IP address of the server that will receive the update, as shown in Figure 9.12.

Figure 9.12. Setting up zone transfers.

7.
Click OK to save the changes.

Note

In addition to specifically defining recipients of zone transfers by IP address, you can select the Only To Servers Listed On The Name Servers Tab radio button as well, assuming that the recipient server or servers are listed under the Name Servers tab.

Performing Full Zone Transfers

The standard method for zone transfers, which transfers the entire contents of a DNS zone to other servers, is known as asynchronous zone transfer (AXFR) or full zone transfer. This type of zone transfer copies every item in the DNS database to a separate server, regardless of whether the server already has some of the items in the database. Older implementations of DNS utilized AXFR exclusively, and it is still utilized for specific purposes today.

Initiating Incremental Zone Transfers

An incremental zone transfer (IXFR) is a process by which all incremental changes to a DNS database are replicated to another DNS server. This saves bandwidth over AXFR replication changes because only the delta, or changes made to the database since the last zone transfer, are replicated.

IXFR zone transfers are accomplished by referencing an index number that is referenced on the SOA of the DNS server that holds the primary zone. This number is incremented upon each change to a zone. If the server requesting the zone transfer has an index number of 45, for example, and the primary zone server has an index number of 55, only those changes made during the period of time between 45 and 55 will be incrementally sent to the requesting server via an IXFR transfer. However, if the difference in index numbers is too great, the information on the requesting server will be assumed stale, and a full AXFR transfer will be initiated. For example, if a requesting server has an index of 25, and the primary zone server's index is 55, an AXFR zone transfer will be initiated, as illustrated in Figure 9.13.

Figure 9.13. IXFR zone transfers.

Previous Page
Next Page


DNS Queries

The primary function of DNS is to provide name resolution for requesting clients, so the query mechanism is subsequently one of the most important elements in the system. Two types of queries are commonly made to a DNS database: recursive and iterative.

Recursive Queries

Recursive queries are most often performed by resolvers, or clients that need to have a specific name resolved by a DNS server. Recursive queries are also accomplished by a DNS server if forwarders are configured to be used on a particular name server. A recursive query essentially asks whether a particular record can be resolved by a particular name server. The response to a recursive query is either negative or positive. A common recursive query scenario is illustrated in Figure 9.14.

Figure 9.14. Recursive and iterative queries.

Iterative Queries

Iterative queries ask a DNS server to either resolve the query or make a best guess referral to a DNS server that may contain more accurate information about where the query can be resolved. Another iterative query is then performed to the referred server and so on until a result, positive or negative, is obtained.

In the example shown in Figure 9.14, Client1 in CompanyABC opens a Web browser and attempts to browse to the Web site for www.microsoft.com. A recursive query is initiated to the default name server; in this case, Server1 is contacted. Because Server1 is authoritative only for the companyabc.com namespace, and no entries exist for microsoft.com, the query is sent to an "upstream" DNS server that is listed in the root hints of the DNS server. That server, Server2, is not authoritative for microsoft.com but sends a referral back to Server1 for Server3, which is a name server for the .com namespace. Server3 knows that Server4 handles name-resolution requests for microsoft.com and sends that information back to Server1. A final iterative query is then sent from Server1 to Server4, and Server4 successfully resolves www to the proper IP address. Server1, with this information in hand, returns Client1's original recursive query with the proper IP address and Client1's browser successfully resolves www.microsoft.com.

This type of functionality lies at the heart of the distributed nature of DNS and allows DNS lookups to function as efficiently as they do.


Other DNS Components

Several other key components lie at the heart of DNS and are necessary for it to function properly. In addition, you need to fully understand the functionality of several key components of DNS that are utilized heavily by Microsoft DNS.

Dynamic DNS

Older versions of DNS relied on administrators manually updating all the records within a DNS database. Every time a resource was added or information about a resource was changed, the DNS database was updated, normally via a simple text editor, to reflect the changes. Dynamic DNS was developed as a direct response to the increasing administrative overhead that was required to keep DNS databases functional and up to date. With Dynamic DNS, clients can automatically update their own records in DNS, depending on the security settings of the zone.

It is important to note that only Windows 2000/XP and higher clients support dynamic updates and that down-level (NT/9x) clients must have DHCP configured properly in order for them to be updated in DNS. There are, however, security issues associated with this functionality that will be detailed in subsequent sections of this chapter and will be described further in Chapter 10, "DHCP/WINS/Domain Controllers."

The Time to Live Value

The Time to Live (TTL) value for a server is the amount of time (in seconds) that a resolver or name server will keep a cached DNS request before requesting it again from the original name server. This value helps to keep the information in the DNS database relevant. Setting TTL levels is essentially a balancing act between the need for updated information and the need to reduce DNS query traffic across the network.

In the example from the "Iterative Queries" section, if Client1 already requested the IP of www.microsoft.com, and the information was returned to the DNS server that showed the IP address, it would make sense that that IP address would not change often and could therefore be cached for future queries. The next time another client requests the same information, the local DNS server will give that client the IP address it received from the original Client1 query as long as the TTL has not expired. This helps to reduce network traffic and improve DNS query response time.

The TTL for a response is set by the name server that successfully resolves a query. In other words, you may have different TTLs set for items in a cache, based on where they were resolved and the TTL for the particular zone they originated from.

The TTL setting for a zone is modified via the SOA record. The procedure for doing this in Windows Server 2003 is as follows:

1.
Open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.
Navigate to DNS\<Servername>\Forward Lookup Zones\<Zonename>.

3.
Find the SOA record for the zone and double-click it.

4.
Modify the Minimum (Default) TTL entry to match the TTL you want, as shown in Figure 9.15.

Figure 9.15. Changing the TTL.

5.
Click OK to accept the changes.

Performing Secure Updates

One of the main problems with a Dynamic DNS implementation lies with the security of the update mechanism. If no security is enforced, nothing will prevent malicious users from updating a record for a server, for example, to redirect it to their own IP address. For this reason, dynamic updates are, by default, turned off on new standard zones that are created in Windows Server 2003. However, with AD-integrated DNS zones, a mechanism exists that will allow clients to perform secure dynamic updates. Secure updates utilize Kerberos to authenticate users and ensure that only those clients that created a record can subsequently update the same record.

If you're using DHCP to provide secure updates, one important caveat is that DHCP servers should not be located on the domain controller, if possible, because of specific issues in regard to secure updates. The reason for this recommendation is that all DHCP servers are placed in a group known as DNSUpdateProxy. Any members of this group do not take ownership of items that are published in DNS. This group was created because DHCP servers often dynamically publish updates for clients automatically, and the clients would need to modify their entries themselves. Subsequently, the first client to access a newly created entry would take ownership of that entry. Because domain controllers create sensitive SRV records and the like, it is not wise to use a domain controller as a member of this group, and it is subsequently not wise to have DHCP on domain controllers for this reason. If establishing DHCP on a domain controller is unavoidable, it is recommended to disable this functionality by not adding the server into this group.

Aging and Scavenging

DNS RRs often become stale, or no longer relevant, as computers are disconnected from the network or IP addresses are changed without first notifying the DNS server. The process of scavenging those records removes them from a database after their original owners do not update them. Scavenging is not turned on, by default, but this feature can be enabled in Windows Server 2003 by following these steps:

1. | Open the DNS MMC snap-in (Start, Administrative Tools, DNS).
2. | Right-click the server name and choose Properties.
3. | Select the Advanced tab.
4. | Check the Enable Automatic Scavenging of Stale Records box.
5. | Select a scavenging period, as shown in Figure 9.16, and click OK to save your changes.

Figure 9.16. Turning on scavenging.

Scavenging makes a DNS database cleaner, but aggressive scavenging can also remove valid entries. It is therefore wise, if you're using scavenging, to strike a balance between a clean database and a valid one.

Root Hints

By default, a DNS installation includes a listing of Internet-level name servers that can be used for name resolution of the .com, .net, .uk, and like domain names on the Internet. When a DNS server cannot resolve a query locally in its cache or in local zones, it consults the Root Hints list, which indicates which servers to begin iterative queries with.

The Hints file should be updated on a regular basis to ensure that the servers listed are still relevant. This file is located in \%systemroot%\system32\DNS\cache.dns and can be updated on the Internet at the following address:

ftp://ftp.rs.internic.net/domain/named.cache

Forwarders

Forwarders are name servers that handle all iterative queries for a name server. In other words, if a server cannot answer a query from a client resolver, servers that have forwarders simply forward the request to an upstream forwarder that will do the iterative queries to the Internet root name servers. Forwarders are used often in situations in which an organization utilizes the DNS servers of an ISP to handle all name-resolution traffic. Another common situation occurs when Active Directory's DNS servers handle all internal AD DNS resolution but forward outbound DNS requests to another DNS environment within an organization, such as a legacy Unix BIND server.

In conditional forwarding, queries that are made to a specific domain or set of domains are sent to a specifically defined forwarder DNS server. This type of scenario is normally used to define routes that internal domain resolution traffic will follow. For example, if an organization controls the companyabc.com domain namespace and the companyxyz.com namespace, it may want queries between domains to be resolved on local DNS servers, as opposed to being sent out to the Internet just to be sent back again so that they are resolved internally.

Forward-only servers are never meant to do iterative queries, but rather to forward all requests that cannot be answered locally to a forwarder or set of forwarders. If those forwarders do not respond, a failure message is generated.

If you plan to use forwarders in a Windows Server 2003 DNS environment, you can establish them by following these steps:

1. | Open the DNS MMC snap-in (Start, Administrative Tools, DNS).
2. | Right-click the server name and choose Properties.
3. | Select the Forwarders tab.
4. | In the DNS Domain box, determine whether conditional forwarders will be established. If so, add them by clicking the New button.
5. | Add the IP address of the forwarders into the Selected Domain's Forwarder IP Address List box, as shown in Figure 9.17.
6. | If this server will be configured only to forward, and to otherwise fail if forwarding does not work, check the Do Not Use Recursion for This Domain box.
7. | Click OK to save the changes.

Figure 9.17. Setting up forwarders.

Using WINS for Lookups

In environments with a significant investment in WINS lookups, the WINS database can be used in conjunction with DNS to provide for DNS name resolution. If a DNS query has exhausted all DNS methods of resolving a name, a WINS server can be queried to provide for resolution. This method creates several WINS RRs in DNS that are established to support this approach.

To enable WINS to assist with DNS lookups, follow these steps:

1. | Open the DNS MMC snap-in (Start, Administrative Tools, DNS).
2. | Navigate to DNS\<Servername>\Forward Lookup Zones.
3. | Right-click the zone in question and choose Properties.
4. | Choose the WINS tab.
5. | Check the Use WINS Forward Lookup box.
6. | Enter the IP address of the WINS Server(s), click Add, and then click OK to save the changes.


The Evolution of Microsoft DNS

Windows Server 2003's implementation of Active Directory expands upon the advanced feature set that Windows 2000 DNS introduced. Several key functional improvements were added, but the overall design and functionality changes have not been significant enough to change any Windows 2000 design decisions that were previously made regarding DNS. The following sections describe the functionality introduced in Windows 2000 DNS that has been carried over to Windows Server 2003 DNS and helps to distinguish it from other DNS implementations.

Active DirectoryIntegrated Zones

The most dramatic change in Windows 2000's DNS implementation was the concept of directory-integrated DNS zones, known as AD-integrated zones. These zones were stored in Active Directory, as opposed to in a text file as in standard DNS. When the Active Directory was replicated, the DNS zone was replicated as well. This also allowed for secure updates, using Kerberos authentication, as well as the concept of multimaster DNS, in which no one server is the master server and all DNS servers contain a writable copy of the zone.

Windows Server 2003 utilizes AD-integrated zones, but with one major change to the design. Instead of storing the zone information directly in the naming contexts of Active Directory, it is stored in the application partition to reduce replication overhead. You can find more information on this concept in the following sections.

Dynamic Updates

As previously mentioned, dynamic updates, using Dynamic DNS (DDNS), allow clients to automatically register and unregister their own host records as they are connected to the network. This concept was a new feature with Windows 2000 DNS and is carried over to Windows Server 2003.

Unicode Character Support

Introduced in Windows 2000 and supported in Windows Server 2003, Unicode support of extended character sets enables DNS to store records written in Unicode, or essentially multiple character sets from many different languages. This functionality essentially allows the DNS server to utilize and perform lookups on records that are written with nonstandard characters, such as underscores, foreign letters, and so on.

Note

Although Microsoft DNS supports Unicode characters, it is best practice that you make any DNS implementation compliant with the standard DNS character set so that you can support zone transfers to and from non-Unicodecompliant DNS implementations such as Unix BIND servers. This includes az, AZ, 09, and the hyphen (-) character.


DNS Changes in Windows Server 2003

In addition to the changes in Windows 2000 DNS, the Windows Server 2003 improvements help to further establish DNS as a reliable, robust name-resolution strategy for Microsoft and non-Microsoft environments. An overall knowledge of the increased functionality and the structural changes will help you to further understand the capabilities of DNS in Windows Server 2003.

DNS Is Stored in the Application Partition

Perhaps the most significant change in Windows Server 2003's DNS, Active Directoryintegrated zones are now stored in the application partition of the AD. For every domain in a forest, a separate application partition is created and is used to store all records that exist in each AD-integrated zone. Because the application partition is not included as part of the global catalog, DNS entries are no longer included as part of global catalog replication.

Previously, in Windows 2000, all AD-integrated zones were stored as global catalog objects and replicated to all global catalog servers in an entire forest. Many times, this information was not applicable across the entire forest, and unnecessary replication traffic was created. Subsequently, the application partition concept was enacted, and replication loads are now reduced, while important zone information is delegated to areas of the network where they are needed.

Automatic Creation of DNS Zones

The Configure a DNS Server Wizard, as demonstrated in "Installing DNS Using the Configure Your Server Wizard" section, allows for the automatic creation of a DNS zone through a step-by-step wizard. This feature greatly eases the process of creating a zone, especially for Active Directory. The wizard can be invoked by right-clicking on the server name in the DNS MMC and choosing Configure a DNS Server.

No "Island" Problem

Windows 2000 previously had a well-documented issue that was known as the "island" problem, which was manifested by a DNS server that pointed to itself as a DNS server. If the IP address of that server changed, the DNS server updated its own entry in DNS, but then other DNS servers within the domain were unable to successfully retrieve updates from the original server because they were requesting from the old IP address. This effectively left the original DNS server in an "island" by itself, hence the term.

Windows Server 2003 DNS first changes its host records on a sufficient number of other authoritative servers within DNS so that the IP changes made will be successfully replicated, thus eliminating this "island" problem. As a result, it is no longer necessary to point a root DNS server to another DNS server for updates, as was previously recommended as a method of resolving this issue.

Forest Root Zone for _msdcs Moved to Separate Zone

In Active Directory, all client logons and lookups are directed to local domain controllers and global catalog servers through references to the SRV records in DNS. These SRV records were stored in a subdomain to an Active Directory domain that was known as the _msdcs subdomain.

In Windows Server 2003, _msdcs has been relocated to become a separate zone in DNS, as shown in Figure 9.18. This zone, stored in the application partition, is replicated to every domain controller that is a DNS server. This listing of SRV records was moved mainly to satisfy the requirements of remote sites. In Windows 2000, these remote sites had to replicate the entire DNS database locally to access the _msdcs records, which led to increased replication time and reduced responsiveness. If you delegate the SRV records to their own zone, only this specific zone can be designated for replication to remote site DNS servers, saving replication throughput and increasing the response time for clients.

Figure 9.18. The _msdcs zone.

[View full size image]


DNS in an Active Directory Environment

DNS is inseparable from Active Directory. In fact, the two are often confused for one another because of the similarities in their logical structures.

Active Directory uses a hierarchical X.500-based structure that was designed to map into the DNS hierarchy, hence the similarities. In addition, Active Directory utilizes DNS for all internal lookups, from client logins to global catalog lookups. Subsequently, strong consideration into how DNS integrates with Active Directory is required for those considering deploying or upgrading AD.

The Impact of DNS on Active Directory

As any Windows 2000 administrator can attest, problems with DNS can spell disaster for an Active Directory environment. Because all servers and clients are constantly performing lookups on one another, a break in name-resolution service can severely affect Active Directory activity.

For this and other reasons, installing a redundant DNS infrastructure in any Active Directory implementation is strongly recommended. Even smaller environments should consider duplication of the primary DNS zone, and nearly as much emphasis as is put into protecting the global catalog AD index should be put into protecting DNS.

Security considerations for the DNS database should not be taken for granted. Secure updates to AD-integrated zones are highly recommended, and keeping DHCP servers off a domain controller can also help to secure DNS. (See previous sections of this chapter for more details on this concept.) In addition, limiting administrative access to DNS will help to mitigate problems with unauthorized "monkeying around" with DNS.

Active Directory in Non-Microsoft DNS Implementations

Active Directory was specifically written to be able to co-exist and, in fact, utilize a non-Microsoft DNS implementation as long as that implementation supports active updates and SRV records. For example, AD will function in all versions of Unix BIND 8.1.2 or higher. With this point in mind, however, it is still recommended that an organization with a significant investment in Microsoft technologies consider hosting Active Directory DNS on Windows Server 2003 systems because functionality enhancements provide for the best fit in these situations.

For environments that use older versions of DNS or are not able (or willing) to host Active Directory clients directly in their databases, Active Directory DNS can simply be delegated to a separate zone in which it can be authoritative. The Windows Server 2003 systems can simply set up forwarders to the foreign DNS implementations to provide for resolution of resources in the original zone.

Using Secondary Zones in an AD Environment

Certain situations in Active Directory require the use of secondary zones to handle specific name resolution. For example, in peer-root domain models, where two separate trees form different namespaces within the same forest, secondaries of each DNS root were required in Windows 2000 to maintain proper forest-wide synchronization.

Because each tree in a peer-root model is composed of independent domains that may not have security privileges in the other domains, a mechanism will need to be in place to allow for lookups to occur between the two trees. The creation of secondary zones in each DNS environment will provide a solution to this scenario, as illustrated in Figure 9.19. Windows Server 2003 now has the option of replicating these separate trees to all DNS servers in the forest, reducing the need for secondaries. Replicating secondary zones outside of a forest is still sometimes necessary, however.

Figure 9.19. Peer-root domain DNS secondary zones.

SRV Records and Site Resolution

All Active Directory clients use DNS for any type of domain-based lookups. Logins, for example, require lookups into the Active Directory for specific SRV records that indicate the location of domain controllers and global catalog servers. Windows Server 2003, as previously mentioned, divides the location of the SRV records into a separate zone, which is replicated to all domain controllers that have DNS installed on them.

Subdomains for each site are created in this zone; they indicate which resource is available in those specific sites. In a nutshell, if an SRV record in the specific site subdomain is incorrect, or another server from a different site is listed, all clients in that site are forced to authenticate in other sites. This concept is important because a common problem is that when Active Directory sites are created before they are populated with servers, an SRV record from the hub location is added to that site subdomain in DNS. When a new server is added to those sites, their SRV records join the other SRV records that were placed there when the site was created. These records are not automatically deleted, and they consequently direct clients to servers across slow WAN links, often making login times very slow.

In addition to the site containers, the root of these containers contains a list of all domain controllers in a specific domain, as shown in Figure 9.20. These lists are used for name resolution when a particular site server does not respond. If a site domain controller is down, clients randomly choose a domain controller in this site. It is therefore important to make sure that the only entries in this location are servers in fast-connected hub sites. Proper grooming of these SRV records and placement of servers into their proper site subdomains will do wonders for client login times.

Figure 9.20. Site-level SRV records.

[View full size image]


Troubleshooting DNS

Much has been written about the complexity of DNS, and even more confusion and misconceptions have been written about it. In truth, however, DNS structure is logical, so you can easily troubleshoot it, if you use the proper tools and techniques. A good grasp of these tools and their functionality is a must for proper name-resolution troubleshooting with DNS.

Using the DNS Event Viewer to Diagnose Problems

As any good administrator will know, the Event Viewer is the first place to look when troubleshooting. Windows Server 2003 makes it even more straightforward to use because DNS Events compiled from the Event Viewer are immediately accessible from the DNS MMC console. Parsing this set of logs can help you troubleshoot DNS replication issues, query problems, and other issues.

For more advanced Event Log diagnosis, you can turn on Debug Logging on a per-server basis. It is recommended that this functionality be turned on only as required, however, as log files can fill up fast. To enable Debug Logging, follow these steps:

1. | Open the DNS MMC snap-in (Start, Administrative Tools, DNS).
2. | Right-click on the server name and choose Properties.
3. | Select the Debug Logging tab.
4. | Check Log Packets for Debugging box.
5. | Configure any additional settings as required and click OK.

Using Performance Monitor to Monitor DNS

Performance Monitor is a built-in, often-overlooked utility that allows for a great deal of insight into issues in a network. In regard to DNS, many critical DNS counters can be monitored relating to queries, zone transfers, memory utilization, and other important factors.

Client-Side Cache and HOST Resolution Problems

Windows 2000 and higher clients have a built-in client cache for name resolution that caches all information retrieved from name servers. When requesting lookups, the client resolver parses this cache first, before contacting the name server. Items remain in this cache until the TTL expires, the machine is rebooted, or the cache is flushed. In cases where erroneous information has been entered into the client cache, it can be flushed by typing ipconfig /flushdns at the command prompt.

By default, all clients have a file named HOSTS that provides for a simple line-by-line resolution of names to IP addresses. This file is normally located in \%systemroot%\ system32\drivers\etc. Problems can occur when these manual entries conflict with DNS, and it is therefore wise to ensure that there are not conflicts with this HOSTS file and the DNS database when troubleshooting.

Using the NSLOOKUP Command-Line Utility

The NSLOOKUP command-line utility is perhaps the most useful tool for DNS client troubleshooting. Its functionality is basic, but the information obtained can do wonders for helping to understand DNS problems. NSLOOKUP, in its most basic operation, contacts the default DNS server of a client and attempts to resolve a name that is inputted. For example, to test a lookup on www.companyabc.com, type nslookup www.companyabc.com at the command prompt. Different query types can be also input into NSLOOKUP. For example, you can create simple queries to view the MX and SOA records associated with a specific domain by following these steps, which are illustrated in Figure 9.21.

Figure 9.21. NSLOOKUP on an MX record.

[View full size image]

1. | Open a command-prompt instance by choosing Start, All Programs, Accessories, Command Prompt.
2. | Type nslookup and press Enter.
3. | Type set query=mx and press Enter.
4. | Type <domainname> and press Enter.
5. | Type set query=soa and press Enter.
6. | Type <domainname> and press Enter.

NSLOOKUP's functionality is not limited to these simple lookups. Performing an nslookup /? lists the many functions it is capable of. NSLOOKUP is a tool of choice for many name-resolution problems and is a must in any troubleshooter's arsenal.

Using the IPCONFIG Command-Line Utility

Another important tool for DNS resolution problems is the IPCONFIG utility, the same utility used for common TCP/IP issues. There are several key functions that IPCONFIG offers in regard to DNS. These functions can be invoked from the command prompt with the right flag, detailed as follows:

  • ipconfig /flushdns If you experience problems with the client-side cache, the cache itself can be "flushed" through the invocation of the flushdns flag. This removes all previously cached queries that a client may be storing and is particularly useful if a server name has just changed IP addresses and particular clients have trouble connecting to it.

  • ipconfig /registerdns The registerdns flag forces the client to dynamically reregister itself in DNS, if the particular zone supports dynamic updates.

  • ipconfig /displaydns An interesting but not well-known flag is displaydns. This flag displays the contents of the client-side cache and is useful for troubleshooting specific issues with individual records.

Note

These three flags, as well as a few others, are available only in Windows 2000 or higher clients. Previous clients such as NT 4.0 were limited to more basic functionality with IPCONFIG, and other clients such as Win9x clients used a different utility known as WINIPCFG. As with any utility, more advanced functionality can be unearthed by invoking the utility with a ? flag (ipconfig /?).

Using the TRACERT Command-Line Utility

The TRACERT utility is a valuable resource that gives you an idea of the path that a DNS query takes when being sent over a network. By directing TRACERT at www.microsoft.com, for example, you can get an idea of how many routers and DNS servers the packet is crossing. The way that TRACERT works is simple, but actually quite interesting. A DNS query that has a TTL of 1 is sent out. Because all routers are supposed to drop the TTL by 1 on each packet that they process, this means that the first router will refuse to forward the packet and send that refusal back to the originator. The originating machine then increments the TTL by 1 and resends the packet. This time the packet will make it past the first router and get refused by the second. This process continues until the destination is met, as illustrated in Figure 9.22. Needless to say, using this command-line utility is a simple yet effective way of viewing the path that a DNS query takes as it crosses the Internet.

Figure 9.22. Sample TRACERT results.

[View full size image]

Using the DNSCMD Command-Line Utility

The DNSCMD utility is essentially a command-line version of the MMC DNS console. Installed as part of the Windows Server 2003 Support tools, this utility allows administrators to create zones, modify records, and perform other vital administrative functions. To install the support tools, run the support tools setup from the Windows Server 2003 CD (located in the \support\tools directory). You can view the full functionality of this utility by typing DNSCMD /? at the command line, as illustrated in Figure 9.23.

Figure 9.23. DNSCMD command-line options.

[View full size image]


Summary

DNS has proven itself over time to be a robust, dependable, and extremely scalable solution to name resolution. Windows Server 2003 takes DNS to the next level and builds on the enhancements introduced with Windows 2000 DNS. Whether using DNS for a full-fledged Active Directory implementation or simply setting up an Internet DNS presence, Windows Server 2003's DNS builds on a successful, road-tested base to provide for a functional, reliable enterprise name-resolution strategy.


Best Practices

  • Use Windows 2000/2003 DNS whenever possible to support Active Directory. If you must use a non-Windows DNS to host the AD Zone, ensure that it supports SRV records, such as with BIND version 8.1.2 or higher.

  • Establish a caching-only server in small branch office situations to alleviate large amounts of client query traffic across the network and to eliminate the need to replicate entire DNS zones to remote locations.

  • Configure DHCP to dynamically update DNS information for down-level clients if dynamic records are necessary.

  • Identify the sources of dynamically updated information to prevent problems with reliability.

  • Configure a DNS server to point to itself for DNS queries rather than to another DNS server.

  • Make any DNS implementation compliant with the standard DNS character set so that you can support zone transfers to and from non-Unicodecompliant DNS implementations such as Unix BIND servers. This includes az, AZ, 09, and the hyphen (-) character.

  • Turn on Debug Logging on a per-server basis for more advanced DNS Event Log diagnosis only when required, and turn off this functionality when it's no longer necessary.


Chapter 10. DHCP/WINS/Domain Controllers

In This Chapter

  • Overview of the "Other" Network Services

  • Key Components of an Enterprise Network

  • Dynamic Host Configuration Protocol (DHCP)

  • DHCP Changes in Windows Server 2003

  • DHCP Failover

  • Advanced DHCP Concepts

  • DHCP Security

  • The Windows Internet Naming Service

  • Installing and Configuring WINS

  • Planning, Migrating, and Maintaining WINS

  • Global Catalog Domain Controller Placement


Overview of the "Other" Network Services

Quite often, some of the more important components of a network are overlooked because they consistently do their job and keep a low profile. It's only when a problem erupts with one of these components that their true value arises and attention is paid to them. The Dynamic Host Configuration Protocol (DHCP) and the Windows Internet Naming Service (WINS) are two such services, faithfully performing their functions day in and day out, while often delegated to a beat-up old server under someone's desk.

Although not glamorous, the functionality in DHCP and WINS is critical in a network environment, and a good deal of thought should be put into their design, administration, and functional requirements. This chapter explores these oft-forgotten services and provides best practice design and configuration information for utilizing them.

In addition to information on DHCP and WINS, this chapter explores the functionality of global catalog domain controller servers in Windows Server 2003, specifically focusing on server placement issues. Finally, this chapter explores step by step specific installation requirements for these services and best practice migration scenarios.


Key Components of an Enterprise Network

Although an enterprise network has many functional layers, this chapter focuses on three key components that are critical to the functionality of a Windows Server 2003 environment. These three aspectsnetwork addressing, name resolution, and directory integrationprovide for the base-level functionality expected of any modern enterprise network and provide the backbone for the Windows Server 2003 infrastructure.

Network Addressing

The first critical component of a network is addressing, or allowing clients to assume a logical place in a network so that packets of information can be forwarded to and from the clients. This component was historically accomplished by proprietary network protocols, one for each network operating system (NOS). This gave NOS designers a great deal of flexibility in tailoring the communications components of their network to their specific design needs but made it difficult to exchange information between networks.

The Transmission Control Protocol/Internet Protocol (TCP/IP) was designed to interoperate between different varieties of networks, allowing them to speak a common language. The rise of this protocol coincided with the widespread adoption of the Internet itself, and it was this popularity and ubiquitous use of this protocol that led Microsoft to choose it as the standard protocol for Windows 2000. Windows Server 2003 continues to use TCP/IP as the default network protocol, expanding its place within the Microsoft NOS world.

TCP/IP requires that each node on a network be addressed by a unique IP address, such as 10.23.151.20. Each IP address must be assigned to every node on a network, either manually or by automatic methods. The automatic addressing component is the place where the DHCP service comes in with Windows Server 2003.

DHCP provides the automation of the critical TCP/IP addressing in Windows Server 2003 and makes administration of a network more palatable. You can find more details on DHCP in the "Dynamic Host Configuration Protocol (DHCP)" section later in this chapter.

Name Resolution

The second critical aspect in networks is name resolution. Because humans understand the concept of names better than they do IP addresses, the need arises to translate those sets of numbers into common names.

Windows Server 2003 supports two types of name resolution. The first type, the Domain Name System (DNS), translates IP addresses into fully qualified domain name (FQDN) addresses, which allows them to be addressed in an Active Directory or Internet DNS structure. This type of name resolution, the default (and required) type in Windows Server 2003, is covered in more detail in Chapter 9, "The Domain Name System."

The second type of name resolution, mapping legacy Microsoft NetBIOS names into IP addresses, is provided by WINS. Although it is technically possible (and ideal) to create a Windows Server 2003 environment free of NetBIOS name resolution, the truth is that divorcing a network from WINS dependency is very difficult, so it will remain an active part of network services in most organizations, at least for a few more years. You can find more information on WINS in the "Windows Internet Naming Service" section later in this chapter.

Directory Integration

The final important service that is supplied by a functional enterprise network is directory placement and lookup capability. Having a centralized directory that controls access to resources and provides for centralized administration is a vital function in modern networks.

Active Directory is the directory service that is provided with Windows Server 2003 and is built into many of the operating system components. The servers that handle the login requests and password changes and contain directory information are the domain controllers and global catalog domain controllers, which will be explained in more detail in the "Understanding the Role of the Active Directory Global Catalog" section later in this chapter.

Subsequently, domain controller and global catalog placement is a critical piece of a Windows Server 2003 environment. Special considerations must be made regarding this concept because access to directory lookup and registration is key for client functionality on a network.

Outlining Network Services Changes in Windows Server 2003

Windows Server 2003 introduces several functional improvements to network services. These improvements allow for increased administrative functionality, greater reliability, and an overall increase in value for an organization's network infrastructure.

DHCP improvements such as DHCP Backup and Restore, migration improvements, and WINS advanced database search and filtering enhance the basic capabilities of these networking services and provide for a richer set of tools in configuring a network environment. You can find more information about these capabilities later in the "Automating DHCP Database Backup and Restore" section of this chapter.


Dynamic Host Configuration Protocol (DHCP)

Amazingly little is known about the DHCP service, although it is used in virtually all organizations. The service itself has simple beginnings but has evolved to become an important component in a network environment. Further study into the background and functionality of DHCP is warranted.

Detailing the Need for DHCP

The day-to-day operations of TCP/IP can be complex, as clients must be able to receive and update their network information on a regular basis to keep in step with changes to a network. Each object in a TCP/IP environment requires a unique address that defines its location and provides for a means of routing network packets from place to place. This address, or IP address, must be assigned to each client in a network to allow the clients to communicate using TCP/IP. In the past, many IP addresses were manually distributed as new clients were added to a network. This required a large amount of administrative overhead to maintain, and often resulted in problems in configuration caused by simple typographical errors and basic human error.

An automatic method for distributing IP addresses to clients was subsequently sought as the administrative advantages of such a system were obvious. The search for such a system led to the predecessors of DHCP: RARP and BOOTP.

DHCP Predecessors: RARP and BOOTP

The need for dynamic allocation of IP addresses to clients was first addressed by the Reverse Address Resolution Protocol (RARP). RARP simply allocated an IP address to a client after that client requested it through a network broadcast. This protocol was quickly discovered to be ineffective, however, because it did not route beyond a single network and could assign only IP addresses, and not subnet masks, gateways, or other important information for TCP/IP.

The successor to RARP was the Bootstrap Protocol (BOOTP), which improved the dynamic assignment of IP addresses by allowing for routing through different networks and used a concept called a magic cookie, a 64-byte portion of the BOOTP packet that contained configuration information such as subnet mask, DNS server designations, and so on. This protocol was a drastic improvement over RARP but was still limited in a few functional areasnamely, in the fact that the database was not dynamic and was stored in a static text file, which limited its usability.

The DHCP Server Service

The Dynamic Host Configuration Protocol (DHCP) was developed as an improvement to BOOTP. In fact, a DHCP packet is almost identical to a BOOTP packet, except for the modification of the magic cookie portion of a packet, which was expanded in size to accommodate additional options such as DNS server, WINS server, and so on.

The DHCP process in itself is straightforward. A client boots up, and a broadcast request is sent out to all nodes on a subnet for which a dynamic IP address is required. The server, which is listening to these broadcasts on UDP port 67, responds to the client request by issuing an IP address in a predefined range, as illustrated in Figure 10.1.

Figure 10.1. The DHCP IP request process.

In addition to an IP address, all options that are defined on the server scope are issued to a client. This includes DNS servers, WINS servers, gateways, subnet masks, and many other possibilities. If these options are issued automatically, the chance for errors is lessened and the entire IP address assignment becomes automated, decreasing administrative overhead.

The DHCP Client Service

The server portion of DHCP is only half of the equation in a DHCP transaction. The request for an IP address comes from a specific interface known as the DHCP client. The client is installed with TCP/IP in Windows 2000 and higher clients and can be installed as an additional component in down-level clients.

The DHCP client, as previously mentioned, handles the communications with the DHCP Server service, in terms of handling IP requests and updates. Each iteration of the Windows client includes a different DHCP client, and there are slight variations in the functionality of each client; however, the overall functionto apply for and receive an IP address from a DHCP serverremains the same in each Windows client.

Automatic Private IP Addressing (APIPA)

The Client/Server service has been updated in Windows 2000 clients and higher, enabling it to automatically assign itself an IP address if no server is available; it does so through a process called Automatic Private IP Addressing (APIPA). APIPA clients automatically assign themselves an IP address in the 169.254.0.0/16 range in this situation, which allows them to have basic TCP/IP connectivity in small networks.

APIPA may be problematic in larger networks because it forces clients to assign themselves addresses in a range that is normally not part of a local company subnet. If a DHCP server is down, clients that are attempting to renew a lease with the server will fail and automatically assign themselves an APIPA address. When the server comes back online, they will not immediately re-register themselves and will effectively be cut off from the network. Subsequently, Microsoft supplies a Registry key that will disable APIPA in this situation. The key to be created is

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<AdapterName>\
_IPAutoconfigurationEnabled:REG_DWORD=0

You can create this key by following these steps on the client:

1. | Open Registry Editor (choose Start, Run and then enter regedit).
2. | Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\_Interfaces\<AdapterName> (where AdapterName is the hexadecimal representation of the network adapter in question).
3. | Right-click on the <AdapterName> key and choose New, DWORD Value.
4. | Enter IPAutoconfigurationEnabled to rename the DWORD value.
5. | Double-click the new value and ensure that 0 is entered as the value data.
6. | Click OK and close the Registry Editor.

Note

APIPA can also be effectively disabled in Windows XP clients through an alternate IP configuration, which allows for the designation of a static IP address if DHCP is unavailable. You can find more information on this concept later in this chapter.

DHCP Relay Agents

Because DHCP clients use network broadcasts to seek out DHCP servers, it is important that this traffic is routed properly on a network with multiple subnets. Effectively, this means that there must be some type of agent to detect DHCP broadcast packets and forward them to the appropriate DHCP server, if it is located on another network. For Cisco routers, for example, this takes the form of an ip-helper enTRy in the router configuration that designates the destination IP address for broadcast packets to be forwarded to. If this type of router configuration is not utilized, a Windows server running the Routing and Remote Access service must be configured as a DHCP relay agent, as illustrated in Figure 10.2.

Figure 10.2. DHCP broadcast packet routing.

Note

In most real-world implementations of DHCP, the routers between network segments are configured to forward client DHCP broadcast packets directly to the DHCP server. In large organizations, it is therefore important to include the network architecture team in any discussions on DHCP design.

DHCP and Dynamic DNS

Using the DNS Service in Windows Server 2003, clients can automatically register themselves in the DNS database through a mechanism called Dynamic DNS (DDNS). For more information on this concept, refer to Chapter 9.

DHCP in Windows Server 2003 integrates directly with DDNS to provide for automatic registration of clients into DNS. By default, all Windows 2000 or higher clients will perform this function by themselves, but DHCP can be configured to allow for the Server service to update the Dynamic DNS record for the client if that client is unable to perform the update itself. This option can be turned on and off at the server level, through the DHCP Manager MMC.

Installing DHCP and Creating New Scopes

DHCP installation has always been a straightforward process. In Windows Server 2003, installation has been even more streamlined through the use of the Configure Your Server Wizard. This wizard installs the DHCP Server service and automatically invokes the New Scope Wizard, which can be used to establish and configure DHCP scopes. To establish a Windows Server 2003 system as a DHCP server, follow these steps:

1.
Choose Start, All Programs, Administrative Tools, Configure Your Server Wizard.

2.
Click Next at the Welcome screen.

3.
Verify the preliminary steps and click Next to continue. A network test will be completed at this point.

4.
Select DHCP Server and click Next.

5.
Verify the options on the next screen, as illustrated in Figure 10.3, and click Next.

Figure 10.3. Verifying options for DHCP install.

[View full size image]

6.
At this point, the New Scope Wizard will be invoked and the process of configuring a scope will begin. Click Next to continue.

7.
Type a name for the scope and enter a description. The names should be descriptive, such as 10.1.1.0/24 Scope. Click Next to continue.

8.
Enter the range in which the scope will distribute IP addresses. In addition, type in a subnet mask for the subnet in question, as illustrated in Figure 10.4. Click Next to continue.

Figure 10.4. Defining the address in the New Scope Wizard.

9.
Enter any exclusion ranges, if necessary. This range will identify any addresses that fall in the scope range that will not be utilized for the client leases. Click Next when finished.

10.
Enter a duration time for the lease. This information will indicate how often clients must renew their DHCP leases. Click Next to continue.

11.
At the next screen, you can add DHCP options to the scope. In this example, configure a gateway, a WINS server, and a DNS server as options for the scope, so choose Yes, I Want to Configure These Options Now and click Next.

12.
Enter the IP address of the default gateway to be used on this subnet and click Next.

13.
Enter the necessary information into the DNS server information fields and click Next when finished.

14.
Enter the WINS server information on the next screen and click Next when finished.

15.
Select whether the scope will be activated immediately or later. In this case, because the server has not been authorized, choose to activate later. After the change, click Next to continue.

16.
Click Finish to close the wizard.

17.
The Configure Your Server Wizard then indicates that the server has successfully become a DHCP server, as indicated in Figure 10.5. Click Finish to close the wizard.

Figure 10.5. Completion of the Configure Your Server Wizard for DHCP.

[View full size image]

Note

Because DHCP can potentially "steal" valid clients from a production network, it is recommended that all tests utilizing DHCP be conducted in a lab environment. In addition, testing in production will be difficult because the Authorization component of DHCP will also make it impossible to enable scopes on a Windows Server 2003 DHCP server, as described in the "DHCP Authorization" section later in this chapter.


DHCP Changes in Windows Server 2003

As previously discussed, two improvements have been made to the functionality of DHCP in Windows Server 2003. These improvements allow for an increased level of functionality beyond the major improvements made in Windows 2000, but do not significantly change any design decisions that may have been made in Windows 2000 DHCP.

Automating DHCP Database Backup and Restore

The process of backing up all DHCP settings and restoring them onto the same (or a different) server has been streamlined in Windows Server 2003. No longer do you need to export Registry keys and manually move databases between servers to migrate DHCP as the Backup and Restore process can be accomplished directly from the MMC. The process for backing up and restoring a DHCP database is as follows:

1.
Open the DHCP Manager (Start, All Programs, Administrative Tools, DHCP).

2.
Right-click the server name and choose Backup, as illustrated in Figure 10.6.

Figure 10.6. Backing up a DHCP database.

[View full size image]

3.
Specify a location for the backup file and click OK. The backup files will then be saved into the location you chose.

4.
Open the DHCP Manager again (Start, All Programs, Administrative Tools, DHCP).

5.
Right-click the server name and choose Restore.

6.
When you see a dialog box asking whether the service can be stopped and restarted, click Yes to continue. The service will be restarted, and the entire database and Registry will be restored.

Note

The DHCP Backup and Restore process is extremely useful in migrating existing DHCP server configurations, scopes, and up-to-date lease information to new DHCP servers. However, because down-level (preWindows Server 2003) DHCP servers do not support automatic Backup and Restore, you will need to migrate from these servers by exporting and re-importing the DHCP Registry and manually moving the database files.

DHCP Client Alternate Network Capability

The DHCP client that is included in the Windows Server 2003 client equivalent, Windows XP, can have a static IP address assigned to clients when a DHCP server is unavailable. This static IP address takes the place of the APIPA address that would normally be configured in these cases.

This type of functionality would normally be used on mobile laptop computers that connect to different networks. When a user is at work, for example, his laptop would receive a DHCP address. When the user is at home, however, his laptop would use the backup static IP address defined in the network settings. To configure this functionality on a Windows XP client, perform the following steps:

1. | Choose Start, Control Panel.
2. | Double-click Network Connections.
3. | Right-click the adapter in question and choose Properties.
4. | Select TCP/IP and choose Properties.
5. | Select the Alternate Configuration tab.
6. | Enter the appropriate Static IP Information and click OK.
7. | Click the Close button to shut the property page.


DHCP Failover

The importance of DHCP cannot be understated. Downtime for DHCP translates into hordes of angry users who can no longer access the network. Consequently, it is extremely important to build redundancy into the DHCP environment and provide for disaster recovery procedures in the event of total DHCP failure.

Unfortunately, the DHCP service has no method of dynamically working in tandem with another DHCP server to synchronize client leases and scope information. However, using a few tricks, you can configure a failover DHCP environment that will provide for redundancy in the case of server failure or outage. Three specific options will provide for redundancy, and the pros and cons of each should be matched to the requirements of your organization.

The 50/50 Failover Approach for DHCP Fault Tolerance

The 50/50 failover approach effectively uses two DHCP servers that each handle an equal amount of client traffic on a subnet. Each DHCP server is configured with similar scope, but each must have a different IP range to avoid IP addressing conflicts.

Figure 10.7 illustrates the 50/50 failover approach. As indicated in the diagram, the network has 200 clients defined by 192.168.1.0/24. Each DHCP server contains a scope to cover the entire specific client subnet. Server1's scope is configured with exclusions for all IPs except for the range of 192.168.1.1192.168.1.125. Server2's scope is configured with exclusions for the first half and a client lease range of 192.168.1.126192.168.1.254.

Figure 10.7. The 50/50 failover approach.

[View full size image]

Upon requesting a client IP address, the first server to respond to a request will be accepted, thus roughly balancing the load between the two servers.

The advantage to this approach is that a degree of redundancy is built into the DHCP environment without the need for extra IP address ranges reserved for clients. However, several caveats must be considered before implementing this approach.

First and foremost, it is theoretically possible that one server is located closer to the majority of the clients, and therefore more clients would be directed to that particular server. This could theoretically cause the DHCP server to run out of client leases, making it ineffectual for redundancy. For this reason, it is preferable to consider other methods of failover for DHCP, if sufficient lease ranges are available.

Another important consideration whenever configuring DHCP servers in this method is that an exclusion range must be established for the range that exists on the other server so that when a client from the other server attempts to renew the lease, it is not refused a new lease. This situation could potentially occur if the exclusion is not established because the client and server would have trouble negotiating if the client was using an IP address out of the range that exists in the scope. Consequently, if the range exists, but an exclusion is established, the server will simply assign a new address in the backup range.

The 80/20 Failover Approach to DHCP Fault Tolerance

The 80/20 failover approach is similar to the 50/50 approach, except that the effective scope range on the server designated as the backup DHCP server contains only 20% of the available client IP range. In most cases, this server that holds 20% would be located across the network on a remote subnet, so it would not primarily be responsible for client leases. The server with 80% of the range would be physically located closer to the actual server, thus accepting the majority of the clients by responding to their requests faster, as illustrated in Figure 10.8.

Figure 10.8. The 80/20 failover approach.

[View full size image]

In the event of Server1's failure, Server2 would respond to client requests until Server1 could be re-established in the network.

The downside to this approach is that if Server1 is down for too long a period of time, it would eventually run out of potential leases for clients, and client renewal would fail. It is therefore important to establish a disaster recovery plan for the server with 80% of the scopes so that downtime is minimized.

Just as with the 50/50 approach, it is important to establish exclusion ranges for the other DHCP server's range, as described in the previous sections.

The 100/100 Failover Approach to DHCP Fault Tolerance

The 100/100 failover approach in Windows Server 2003 DHCP is the most effective means of achieving high availability out of a DHCP environment. However, several big "gotchas" must be worked out before this type of redundancy can be implemented.

The 100/100 failover approach in its simplest form consists of two servers running DHCP, with each servicing the same subnets in an organization. The scopes on each server, however, contain different, equivalent size ranges for clients that are each large enough to handle all clients in a specific subnet.

In Figure 10.9, the 10.2.0.0/16 subnet has a total of 750 clients. This subnet is serviced by two DHCP servers, each of which has a scope for the subnet. Each server has a scope with addresses from 10.2.1.1 through 10.2.8.254. The scope on Server1 excludes all IP addresses except those in the range of 10.2.1.1 through 10.2.4.254. The scope on Server2 excludes all IP addresses except those in the range from 10.2.5.1 through 10.2.8.254. Each effective range is subsequently large enough to handle 1,000 clients, more than enough for every machine on the network.

Figure 10.9. The 100/100 failover approach.

[View full size image]

If one of the DHCP servers experiences an interruption in service, and it no longer responds, the second server will take over, responding to clients and allowing them to change their IP addresses to the IPs available in the separate range.

The advantages to this design are obvious. In the event of a single server failure, the second server will immediately issue new IP addresses for clients that previously used the failed server. Because both servers run constantly, the failover is instantaneous. In addition, the failed DHCP server could theoretically remain out of service for the entire lease duration because the second server will be able to pick up all the slack from the failed server.

The main caveat to this approach is that a large number of IP addresses must be available for clients, more than twice the number that would normally be available. This may prove difficult, if not impossible, in many networks that have a limited IP range to work with. However, in organizations with a larger IP range, such as those offered by private network configurations (10.x.x.x and so on), this type of configuration is ideal.

As you can see in Figure 10.9, both ranges must include the scopes from the other servers to prevent the types of problems described in the preceding examples.

Note

If your organization uses a private IP addressing scheme such as 10.x.x.x or 192.168.x.x, it is wise to segment available IP addresses on specific subnets to include several times more potential IP addresses than are currently required in a network. This not only ensures effective DHCP failover strategies, but it also allows for robust network growth without the need for an IP addressing overhaul.

Standby Scopes Approach

A standby DHCP server is simply a server with DHCP installed, configured with scopes, but not turned on. The scopes must be configured in different ranges, as in the previous examples, but they normally lie dormant until they are needed. The advantage to this approach lies in the fact that the DHCP service can be installed on a server that will not normally be using additional resources for DHCP. In the case of a problem, you simply need to activate the dormant scopes. An automated tool or script can be used to perform this function, if desired.

Clustering DHCP Servers

The final redundancy option with DHCP is to deploy a clustered server set to run DHCP. In this option, if a single server goes down, the second server in a cluster will take over DHCP operations. This option requires a greater investment in hardware and should be considered only in specific cases in which it is necessary. For more information on clustering servers, see Chapter 31, "System-Level Fault Tolerance (Clustering/Network Load Balancing)."


Advanced DHCP Concepts

DHCP has been an unassuming network service as of late. The simplicity of the protocol is another reason for its success because it is not cursed by a high degree of administrative complexity. However, greater control over a DHCP environment can be achieved through the understanding of some advanced concepts regarding its use. Some of these concepts are new to Windows Server 2003, and some were introduced in Windows 2000. These improvements can help you to gain control over a DHCP environment, and provide for more security and ease of use.

DHCP Superscopes

A DHCP Superscope is used for environments in which multiple network subnets encompass a single scope environment. In these cases, a Superscope can be created to contain multiple scopes. The individual scopes are subsequently dependent on the master Superscope. If it is turned off, they will also be deactivated. Figure 10.10 illustrates a sample DHCP Superscope.

Figure 10.10. A DHCP Superscope.

[View full size image]

DHCP Multicast Scopes

A Multicast scope is created to allow clients to be assigned multicast IP addresses. A multicast IP address is one in which destination hosts can each have the same IP address, which is useful in one-to-many forms of communications such as Webcasts and videoconferencing sessions.

Delegating Administration of DHCP

It is never wise to hand over full administrative privileges to individuals who need to perform only a specific network function. If a small group of administrators needs control over the DHCP environment, Windows Server 2003 makes it easy to delegate administrative capabilities to them through the inclusion of a group called DHCP Administrators. Adding users or, preferably, groups to this Security Group will enable those users to administer the DHCP servers in an environment.

Netsh Command-Line Utility

Windows Server 2003 has made great strides in allowing virtually all administrative functions to be performed through the command line. This not only helps those users who are used to command-line administration, such as that in Unix operating systems, but also allows for the execution of scripts and batch files, which can automate administrative processes.

The Netsh command-line utility is one such utility that effectively allows administrators to accomplish virtually all DHCP tasks that can be run through the MMC GUI interface. For a full listing of potential functions with Netsh, run netsh /? from the command line, as illustrated in Figure 10.11.

Figure 10.11. Netsh command-line options.

[View full size image]

Performing DHCP Database Maintenance

The DHCP database is stored in the dhcp.mdb file, located in \%systemroot%\system32\dhcp. This database is structured using Microsoft JET database technology, the same technology used for Exchange Server, Active Directory, and many other databases in the Microsoft world.

As any administrator who has worked with JET databases will attest, frequent maintenance of the DHCP database is required to keep it functioning properly and to groom it for defragmentation and recovery of whitespace. By default, DHCP is configured to perform online maintenance to the database, but only during intervals in which it is not being used for client requests. For busy, large DHCP servers, there may never be downtime, so it is therefore important to run offline maintenance against the dhcp.mdb file on a quarterly to semi-annual basis.

You can run maintenance against the dhcp.mdb DHCP database file by using the jetpack utility in Windows Server 2003. From the command line, enter the following commands, illustrated in Figure 10.12, to stop the DHCP Server service, compact the database, and restart the service:

Figure 10.12. DHCP database maintenance.

[View full size image]

  • cd %systemroot%\system32\dhcp

  • net stop dhcpserver

  • jetpack dhcp.mdb tmp.mdb

  • net start dhcpserver

Note

A maintenance schedule for DHCP and all other Microsoft JET-based databases should be established, in addition to any other maintenance schedules that may be in effect. Such a schedule will help to keep these network services environments in top shape. Using redundant servers that will take over while the database is down can also minimize downtime from this maintenance.


DHCP Security

The DHCP protocol is effectively insecure. There is no way to determine if a request from a client is legitimate or is malicious. Users who have evil intentions can conduct denial-of-service attacks against the DHCP server by simply requesting all available IP addresses in a range, effectively disallowing legitimate users from being granted IP addresses. For this and other reasons, it is important to keep wire security as a high priority. Although this point may seem obvious, keeping potential intruders physically off a network is a must, not only for DHCP but for other network services prone to denial-of-service attacks. This includes auditing the security of wireless networks, such as 802.11b, which can (and often do) provide unrestricted access to malicious users.

In addition to physical and wire security, several security considerations and mechanisms should be examined to provide for a better understanding of the vulnerabilities and capabilities of DHCP.

DHCP Authorization

DHCP in and of itself is an unauthenticated service, which means that anyone can establish a DHCP server on a network and start to accept clients and assign them erroneous addresses or redirect them for malicious purposes. Consequently, since Windows 2000, it has become necessary to authorize a DHCP server that is running in an Active Directory domain. After the DHCP server is authorized by the proper domain administrative authority, that server can then accept client leases.

The downside to this approach is that a Windows NT 4.0 or Linux server could still be added, unauthenticated, to a network. In this situation, it would become necessary to pull out a network analyzer to determine the location of rogue DHCP servers.

Authorization of a Windows Server 2003 DHCP server is straightforward, as long as the server is a member of an AD domain and the user logged in has proper DHCP privilege in the domain. Authorization can be accomplished by following these steps:

1.
Open the DHCP Manager (Start, All Programs, Administrative Tools, DHCP).

2.
Right-click the server name and choose Authorize, as illustrated in Figure 10.13.

Figure 10.13. Authorizing a DHCP server.

[View full size image]

3.
In a few minutes, the DHCP should be authorized, and the scopes can be activated.

DHCP and Domain Controller Security

If at all possible, the DHCP service should not be run on an Active Directory domain controller because the security of the SRV records generated is lost. The reasons for this are as follows.

DNS entries in an Active Directoryintegrated DNS zone are "secure," which means that only the client that originally created the record can subsequently update that same record. This can cause problems if the DHCP server is automatically updating client records, however, as the client no longer performs this function and cannot have security applied to a record.

DHCP in Windows Server 2003 overcomes this limitation by placing all DHCP servers in a special group in Active Directory, called DNSUpdateProxy. Members of this group do not have any security applied to objects that they create in the DNS database. The theory is that the first client to "touch" the record will then take over security for that record.

The problem with this concept is that the records created by DHCP servers possess no immediate security and are consequently subject to takeover by hostile clients. Because domain controllers are responsible for publishing SRV DNS records, which indicate the location of domain controllers, Kerberos servers, and the like, this leaves a gaping security hole that users could exploit. Consequently, it is preferable to keep DHCP off domain controllers. If this cannot be avoided, it is recommended to not place the DHCP server into the DNSUpdateProxy group so as to avoid the security problems associated with it.


The Windows Internet Naming Service

The Windows Internet Naming Service (WINS) has a long and sordid history in Microsoft networks. In the beginning, Microsoft networks were primarily broadcast-based, using protocols such as NetBEUI to identify local computers. The problem with this type of name resolution was that it did not scale beyond multiple subnets, which were fast becoming the norm in modern networks. With the adoption of TCP/IP as an easily routable protocol, the need to translate NetBIOS computer names with IP addresses became a reality. This need gave rise to the development of WINS.

Legacy Microsoft NetBIOS Resolution

WINS is effectively a simple database of NetBIOS names and their corresponding IP addresses. Some additional information, such as domain name, server type, and so on, can be determined as well, from the 16th byte in a NetBIOS name stored in WINS.

WINS is considered legacy in the Microsoft world because NetBIOS resolution is being phased out in favor of the Domain Name System (DNS) form of name resolution. However, it is difficult to divorce WINS from modern networks because of the reliance on WINS by down-level (pre-Windows 2000) clients, legacy applications, and even some Microsoft services such as DFS that utilize NetBIOS resolution by default. Consequently, it is often necessary to keep using WINS in Windows networks, unless it can be definitively proven that it is no longer necessary.

WINS and DNS Integration

DNS can use the WINS database to provide for quasi-DNS resolution of WINS clients. This means that if a request is sent to a DNS server to resolve client1.companyabc.com, for example, it is possible for that DNS server to use the WINS database to resolve requests for any zones where the WINS forward lookup is configured. If Client1 does not exist in the DNS database but exists in the WINS database instead, the DNS server will return the IP address that it obtained from WINS and attach the companyabc.com suffix to the record, as illustrated in Figure 10.14.

Figure 10.14. WINS integration with DNS.

This functionality must be enabled on the DNS server because it is not configured by default. To enable WINS resolution on a DNS server, follow these steps:

1.
On a server running DNS, open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.
Navigate to DNS\<Servername>\Forward Lookup Zones.

3.
Right-click the zone in question and choose Properties.

4.
Choose the WINS tab.

5.
Check the Use WINS Forward Lookup box.

6.
Enter the IP address of the WINS server(s) and click OK to save the changes, as illustrated in Figure 10.15.

Figure 10.15. Configuring WINS resolution in DNS.

For more information on DNS configuration, refer to Chapter 9.

Changes in Windows Server 2003 WINS

Although the overall function of WINS has not changed significantly in Windows Server 2003, some additions to the management tools allow for increased functionality and capabilities:

  • Advanced search capabilities for WINS databases Previous implementations of WINS had simplistic search capabilities that were limited to simple keyword searches of NetBIOS records in the database. The search engine for WINS has been updated in Windows Server 2003 to support more advanced search parameters, thus giving administrators more flexibility in searching for specific records.

  • WINS pull record filtering and replication partner acceptance Instead of entire transfers of all records on other servers, replication can be limited to only those records owned by a specific server, thus excluding extraneous records from littering a WINS database.

In addition to these advances in Windows Server 2003, Windows 2000 introduced enhancements to WINS, such as an updated database engine, persistent connections, manual tombstoning, and other improvements.


Installing and Configuring WINS

As with many services in Windows Server 2003, the installation and configuration process of a WINS server is streamlined through the Configure Your Server Wizard. This wizard automatically installs all necessary services and databases and configures other settings pertinent to a particular service. Although other methods of installation still exist, this method is the preferred approach in Windows Server 2003.

Installing WINS

To install WINS on a server using the Configure Your Server Wizard, follow these steps:

1.
Choose Start, All Programs, Administrative Tools, Configure Your Server Wizard.

2.
Click Next at the Welcome screen.

3.
Verify the preliminary steps and click Next to continue. A network test will then be performed.

4.
Select WINS Server from the list of Server Roles and click Next to continue.

5.
On the Summary page, click Next to continue.

6.
If you are prompted for the Windows Server 2003 Media, insert it and click Next to continue.

7.
Click Finish on the final wizard page to finish setup, as illustrated in Figure 10.16.

Figure 10.16. WINS server installation.

[View full size image]

Configuring Push/Pull Partners

If a WINS server in an environment is the sole WINS server for that network, no additional configuration is required other than ensuring that clients will be pointing to the WINS server in their IP configuration. However, if additional WINS servers are established in an environment, exchanging database information between the multiple servers will become necessary. This type of replication topology is established through the designation of push/pull partners.

A push partner for a particular WINS server is another WINS server that serves as the destination for WINS changes to be "pushed" to. A pull partner is a WINS server from which changes are "pulled." In a nutshell, if Server1 has Server2 configured as a push partner, Server2 must have Server1 configured as a pull partner, and vice versa.

A WINS push/pull topology should roughly map to an organization's network topology. For example, if an organization is composed of two main offices that serve as network hubs, and several branch offices, each with its own WINS servers, the WINS push/pull topology could look something like Figure 10.17.

Figure 10.17. Sample WINS push/pull topology.

WINS Replication

WINS replicates database changes on a set schedule, which can be modified on a perconnection basis. Just as with any network communications, the replication schedule should be modified to fit the particular needs of an organization. If a WAN link is saturated with traffic, it may be wise to throttle back the WINS replication schedule. However, if a link between push/pull partners is robust, a shorter schedule can be established. To change the default schedule of 30 minutes, follow these steps:

1.
Open the WINS Manager (Start, All Programs, Administrative Tools, WINS).

2.
Choose the Replication Partners folder.

3.
Right-click Push/Pull Partner (if one does not exist, it will have to be created) and choose Properties.

4.
Change the Replication Interval time to the desired length, as indicated in Figure 10.18, and click OK to save the settings.

Figure 10.18. WINS replication settings.

The page shown in Figure 10.18 can also be used to change other push/pull partner settings, such as replication partner types, persistent connections, and other pertinent replication information.

NetBIOS Client Resolution and the LMHOSTS File

A Windows client does not immediately resort to a WINS server to determine the IP address of a NetBIOS name. This knowledge is essential in the troubleshooting of name resolution on a Windows client. Instead, a client first contacts a local NetBIOS cache for resolution. If an IP address changes, this cache may report the old address, impeding troubleshooting. To flush this cache, run nbtstat-R (with uppercase R) at the command line.

In addition to the local cache, clients always parse an LMHOSTS file, if one exists, before contacting a WINS server. If the LMHOSTS file contains erroneous information, it will impede proper name resolution. Always check to see whether this file is populated (it is usually located in \%systemroot%\system32\drivers\etc on clients) before beginning to troubleshoot the WINS server.


Planning, Migrating, and Maintaining WINS

As previously mentioned, WINS is necessary in most production environments because the overriding dependencies on NetBIOS that were built into Windows have not entirely been shaken out. In fresh installations of Windows Server 2003, WINS might not be necessary, but for older, upgraded environments, plans should be made for WINS being around for a few years.

Designing a WINS Environment

There are two key factors to consider when designing a WINS environment. The first factor is accessibility. Having a local, fast connection to a WINS server will aid in the processing of client requests. Because WINS has low overhead for servers, it is consequently a good idea to include at least one WINS server in all locations with more than 510 users. In smaller environments, WINS can be installed as part of a local file server; whereas in larger environments, dedicated multiple utility servers running WINS are recommended.

The replication topology to be established should normally follow the lines of a network infrastructure, as previously mentioned. If a network utilizes a hub-and-spoke design, WINS should follow the same basic topology.

Upgrading a WINS Environment

The WINS service itself is one of the more straightforward services to migrate to a separate set of servers as part of an upgrade to Windows Server 2003. A simple upgrade of the existing WINS server will do the trick for many environments; however, migrating to a separate server or set of servers may be beneficial if changing topology or hardware.

Migration of an existing WINS environment is most easily accomplished through the procedure described in this section. This procedure allows for the migration of an entire WINS database to a new set of servers, but without affecting any clients or changing WINS server settings. Figure 10.19 illustrates a WINS migration using this procedure.

Figure 10.19. The first step in the WINS migration procedure.

In Figure 10.19, the existing servers, OldServer1 and OldServer2, handle WINS traffic for the entire network of fictional CompanyABC. They are configured with IP addresses 10.1.1.11 and 10.1.1.12, which are configured in all clients' IP settings as Primary and Secondary WINS, respectively. OldServer1 and OldServer2 are configured as push/pull partners.

The new servers, NewServer1 and NewServer2, are added to the network with the WINS service installed and configured as push/pull partners for each other. Their initial IP addresses are 10.1.1.21 and 10.1.1.22. OldServer1 and NewServer1 are then connected as push/pull partners for the network. Because the servers are connected this way, all database information from the old WINS database is replicated to the new servers, as illustrated in step 1 shown in Figure 10.19.

After the entire WINS database is replicated to the new servers, the old servers are shut down (on a weekend or evening to minimize impact), and NewServer1 and NewServer2 are immediately reconfigured to take the IP addresses of the old servers, as illustrated in step 2 shown in Figure 10.20.

Figure 10.20. The second step in the WINS migration procedure.

The push/pull partner relationship between NewServer1 and NewServer2 is then reestablished because the IP addresses of the servers changed. The entire downtime of the WINS environment can be measured in mere minutes, and the old database is migrated intact. In addition, because the new servers assume the old IP addresses, no client settings need to be reconfigured.

There are a few caveats with this approach, however. If the IP addresses cannot be changed, WINS servers must be changed on the client side. If you're using DHCP, you can do this by leaving all old and new servers up in an environment until the WINS change can be automatically updated through DHCP. Effectively, however, WINS migrations can be made very straightforward through this technique, and they can be modified to fit any WINS topology.

Maintaining the WINS Database

As with the DHCP database, the WINS database is based on the Microsoft JET database technology and subsequently requires regular maintenance. Scheduling maintenance for each WINS database is recommended on a quarterly or semi-annual basis at least. The WINS database file, wins.mdb, is stored in the %systemroot%\system32\wins directory. You can run maintenance against the database by entering the following commands at the command line:

  • cd %systemroot%\system32\wins

  • net stop wins

  • jetpack wins.mdb tmp.mdb

  • net start wins


Global Catalog Domain Controller Placement

The placement of domain controllers in Windows Server 2003 is the critical factor to improve the communication response time from an Active Directory query. Without prompt response from a domain controller, a user may have to wait several seconds to several minutes to merely log on to the network, or it could take a similar length of time to even view the list of email recipients the user wants to send a message to.

This section deals with specific server placement issues for Active Directory domain controllers and global catalog servers. For more in-depth coverage of these concepts, refer to Chapter 4, "Active Directory Primer," and Chapter 5, "Designing a Windows Server 2003 Active Directory."

Understanding the Role of the Active Directory Global Catalog

The global catalog in Active Directory is an index of all objects in an Active Directory forest. All domain controllers in Windows Server 2003's Active Directory are not by default global catalog servers, so they must be established as such through the following procedure:

1.
Open Active Directory Sites and Services.

2.
Navigate to Sites\<SiteName>\Servers\<ServerName>.

3.
Right-click NTDS Settings and select Properties.

4.
Check the Global Catalog box, as indicated in Figure 10.21.

Figure 10.21. Making a domain controller into a global catalog server.

Global Catalog/Domain Controller Placement

It is important to understand that global catalog objects must be physically located close to all objects in a network that require prompt login times and fast connectivity. Because a global catalog entry is parsed for universal group membership every time a user logs in, this effectively means that this information must be close at hand. This can be accomplished by placing GC/DCs on the same WAN site or by using a process new to Windows Server 2003 called universal group caching.

Universal Group Caching

Universal group caching is a process by which an Active Directory site caches all universal group membership locally so that the next time clients log in, information is more quickly provided to the clients and they are able to log in faster.

Universal group caching is more effective than placing a GC/DC server locally because only those universal groups that are relevant to a local site's members are replicated and are cached on the local domain controller. The downside to this approach, however, is that the first login for clients will still be longer than if a local GC/DC were provided, and the cache eventually expires, requiring another sync with a GC/DC.

You can set up universal group caching on a site level as follows:

1.
Open Active Directory Sites and Services.

2.
Navigate to Sites\<Site Name>.

3.
In the right-hand pane, right-click NTDS Site Settings and choose Properties.

4.
Check the Enable Universal Group Membership Caching box, as illustrated in Figure 10.22.

Figure 10.22. Enabling universal group caching.

Global Catalog and Domain Controller Placement

As illustrated in the preceding sections, decisions must be made regarding the most efficient placement of DCs and GC/DCs in an environment. Determining the placement of GC/DCs and universal group caching sites must be done with an eye toward determining how important fast logins are for users in a site compared to higher replication throughput. For many Windows Server 2003 environments, the following rules apply:

  • Sites with fewer than 50 users Use a single DC configured with universal group caching.

  • Sites with 50100 users Use two DCs configured for universal group caching.

  • Sites with 100200 users Use a single GC server and single DC server.

  • Sites with 200+ users Alternate adding additional DCs and GC/DCs for every 100 users.

The recommendations listed here are generalized and should not be construed as relevant to every environment. Some scenarios might call for variations to these approaches, such as when using Microsoft Exchange in a site. However, these general guidelines can help to size an Active Directory environment for domain controller placement.


Summary

While often overlooked, the services of DHCP and WINS are some of the most critical components of a functional Windows Server 2003 environment. In addition, global catalog domain controller placement and related issues are integral to the functionality of an Active Directory environment. Consequently, it is important to have a strong understanding of these components and their related design, migration, and maintenance procedures to ensure the high availability, reliability, and resilience of a network infrastructure.


Best Practices

  • Perform all tests with DHCP in a lab environment.

  • Define a maintenance schedule for DHCP and all other Microsoft JET-based databases.

  • Implement redundancy in a DHCP and WINS infrastructure.

  • Dedicate multiple utility servers running WINS in large environments.

  • Schedule maintenance for each WINS database on a quarterly or semi-annual basis.

  • Properly plan the most efficient placement of DCs and GC/DCs in an environment.

  • Use a single DC configured with universal group caching for AD sites with fewer than 50 users who do not need a local GC for services such as Exchange.

  • Use at least two DCs in AD sites with between 50 and 100 users.


Chapter 11. Internet Information Services v6

In This Chapter

  • Improvements in IIS 6

  • Planning and Designing IIS

  • Installing and Upgrading IIS

  • Configuring IIS

  • Configuring and Optimizing Applications

  • Installing and Configuring FTP Services

  • Examining Optional IIS Components

  • Securing IIS

  • Maintaining IIS

  • Internet Explorer Enhanced Security Configuration for Servers

It's hard to comprehend that with each successor of Internet Information Services (IIS) has come a vast improvement over previous versions of IIS. IIS 6 is no different. It has been reconstructed to increase security safeguards, improve administration and manageability, and incorporate features for the .NET initiative set forth by Microsoft.

Improving upon previous versions and providing the most robust and secure Web services environment have been among the most daunting tasks Microsoft has faced with IIS. However, Microsoft has learned from its own experiences and customers what improvements need to be made. Microsoft has literally gone through each line of IIS code and made appropriate changes to make IIS as secure and robust as possible.


Improvements in IIS 6

Several key enhancements have been made to IIS. These enhancements are designed not only to build upon .NET, but also to increase reliability, performance, and security.

Whereas IIS 5 was designed as a single process, inetinfo.exe, IIS 6 has been redesigned to use four core processes:

  • Http.sys Http.sys is a kernel-mode HTTP listener. Every Web site on the server is registered with Http.sys so that the Web site can receive HTTP requests. Http.sys then is responsible for sending these requests to IIS user-mode processes and requests back to the client. Http.sys has other responsibilities such as managing TCP connections, caching responses, ensuring Quality of Service (QoS), and handling IIS text-based logging.

  • Web Administration Services (WAS) This service is a user-mode configuration and process manager. It is a new component of the World Wide Web Publishing Service (W3SVC). In user-mode configuration, WAS interacts with the IIS metabase to retrieve configuration data. As a process manager, WAS is responsible for starting and managing worker processes.

  • Application handlers/worker processes Worker processes are user-mode applications that process requests such as returning Web pages. These worker processes, controlled by WAS, then service requests for application pools in Http.sys. IIS can have many worker processes, depending on the IIS configuration.

  • IIS Admin Service This service manages non-Web related functions such as File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), Network News Transfer Protocol (NNTP), and the IIS metabase.

These three processes segment IIS from the rest of the Web services to maximize reliability of the Web services' infrastructure.

Many other improvements to IIS are listed here and are categorized in three sections:

Scalability

  • Enhancements to IIS performance, including reduced resource requirements and streamlined processes, allow for faster response times and increased Web server capacity.

  • Native support for 64-bit Web servers allows for increased memory support and processing capabilities. The 64-bit platform can handle greater workloads.

  • Tens of thousands of sites can reside on a single box. This improvement is especially useful for Internet service providers (ISPs) and application service providers (ASPs).

  • Remote server support has been improved for greater administration efficiency.

Security

  • IIS 6 has a reduced default attack surface for hackers and processes to try to gain unauthorized access.

  • Administrators can tighten security using the IIS Lockdown Wizard. This tool allows administrators to enable or disable IIS functionality.

  • IIS defaults to a locked-down state. Only static information (.htm, .jpg, and so on) is served, and additional functionality such as Active Server Pages must be manually enabled.

  • The IIS service account runs with only low privileges.

  • Worker processes are specific to applications and Web sites. Organizations running multiple applications and multiple Web sites on a single Web server benefit from this separation because the worker processes are independent from one another.

  • IIS isolates FTP users. Users can be directed, based on their usernames, to a specific directory to upload and download. Users cannot use or view other directories.

  • Secure Sockets Layer (SSL) implementation has been dramatically improved to increase performance, manageability, and scalability.

  • IIS has built-in support for Kerberos and related standards.

  • IIS now has code access security, which is the complete separation of user-mode code from kernel-mode code. This minimizes security violations from user-mode processes but doesn't negatively affect performance.

  • IIS can support trusted subsystems and other entities such as Passport.

Manageability

  • Process recycling based on time, schedule, hits, and memory consumption can refresh the Web server without stopping service to end users.

  • IIS 6 removes the proprietary IIS metabase found in earlier versions with an Extensible Markup Language (XML) text metabase. The XML metabase can be directly accessed and edited, even when online.

  • Both Web site and application configurations can be quickly and easily imported and exported.

  • Increased support for Windows Management Interface (WMI) scripting allows for greater functionality using scripts.

  • More command-line tools are available, so IIS can be managed through the command line or scripts.


Planning and Designing IIS

Two of the most important tasks to accomplish before implementing IIS are thorough planning and designing. Planning and designing are the beginning phases to properly implementing IIS, and they may consist of the following:

  • Defining goals and objectives of the project

  • Identifying and reviewing IIS application types and requirements

  • Designing the IIS infrastructure to support the goals and objectives

  • Designing the back-end infrastructure such as the database or application tier

  • Defining security requirements to meet the goals and objectives and balancing the security methodologies between risks and end-user experience

  • Examining and designing disaster recovery plans, and monitoring requirements and maintenance practices

  • Documenting the current IIS infrastructure and the IIS design decisions

Determining Server Requirements

Hardware and software requirements are based on the information gathered and the requirements set forth in the design and planning stages. The necessary hardware and software requirements should match the goals and objectives of the project. These details are very specific and describe all the resources needed for hardware and software. For example, four IIS servers will each require dual processors, 1GB RAM, triple-channel RAID controllers, and 15K rpm disk drives.

Determining Fault Tolerance Requirements

Fault tolerance is a key aspect of any Web infrastructure and should be addressed during the planning and designing phases. Although some Web sites can afford to have downtime, others may require 99.999% uptime. Service Level Agreements (SLAs) should be determined from the operational goals. When an SLA is in place, such as a minimum of two hours of downtime at any one time, the appropriate fault tolerance can be applied to the Web infrastructure.

Various technologies can be applied to a Windows Server 2003 Web infrastructure to support even the most demanding SLAs. For example, Windows Server 2003 Web servers can use network load balancing (NLB) to distribute the load among multiple Web servers and also provide fault tolerance. NLB is more suited and less costly than using Microsoft Cluster Service to provide fault tolerance. Another way to promote fault tolerance is to tier the environment so that various services are segmented (for example, IIS tier, application tier, database tier, messaging tier), as shown in Figure 11.1.

Figure 11.1. Fault tolerance using a tier environment.

Previous Page
Next Page


Installing and Upgrading IIS

For the first time, Microsoft has rightfully opted not to include IIS as a default installation option. This way, a file and print server, a domain controller, or any other type of server that isn't supposed to be a Web server won't have IIS installed by default and potentially increase security vulnerabilities.

You must have administrator privileges to be able to install IIS. There are two ways to begin installation: through Add or Remove Programs in the Control Panel or through the Manage Your Server Wizard that is automatically displayed after Windows Server 2003 installation.

To install IIS using Add or Remove Programs in the Control Panel, follow these steps:

1.
Select Add or Remove Programs from the Start, Control Panel menu.

2.
Click Add/Remove Windows Components in the Add or Remove Programs dialog box.

3.
In the Windows Components Wizard, scroll down until you see Application Server. Highlight this entry, click the check box, and then click the Details button.

4.
In the Application Server dialog box, illustrated in Figure 11.2, you can see the list of components (for example, ASP.NET, COM+ access, Internet Information Services, and more) that you can install. If you plan on using any of these services, select them by clicking the check box. For now, highlight Internet Information Services (IIS) and click Details.

Figure 11.2. Application Server components dialog box.

5.
Select the components that you want to install. If you don't click to install a required component, the required components are automatically selected. Click OK twice when you're done.

6.
Click Next in the Windows Components Wizard to begin installing IIS.

7.
Click Finish when installation is complete.

To install IIS using the Manage Your Server Wizard, do the following:

1. | In the Manage Your Server Wizard, click Add or Remove a Role.
2. | When the Configure Your Server Wizard window appears, click Next to continue. Windows Server 2003 will analyze your network configuration. Note You must be connected to the network to run the network-analyzing function; otherwise, you will get an error notifying you to check cables and connections.
3. | Click on Web Application Server (IIS, ASP.NET) and then click Next.
4. | Select any of the two options (FrontPage Server Extensions, or Enable ASP.NET) and click Next to continue.
5. | After reviewing the summary of information, click Next again to begin IIS installation.
6. | Click Finish when the installation is complete.

Although using the Manage Your Server Wizard is easier than using Add or Remove Programs, your ability to control what gets installed is minimal.

Upgrading from Other Versions of IIS

As a previous version of Windows is upgraded to Windows Server 2003, IIS is also automatically upgraded. During Windows Server 2003 setup, all IIS-related services running on the previous Windows version are disabled during the upgrade. These services and more are enabled after the upgrade is complete.

Windows Server 2003's IIS is inherently more secure than any other versions. As a result, all Web sites currently upgraded to IIS 6 are stopped after the upgrade. The primary reason for stopping all Web sites is to help prevent IIS security vulnerabilities because of previous Windows defaults. Therefore, if a previous Windows server has IIS installed but isn't supposed to be serving as a Web server, the servers will be more secure than before by default. In this scenario, Web sites aren't enabled.

Another key point to upgrading from previous versions of IIS is that all applications are configured in the IIS 5 isolation mode. This configuration preserves the applications and provides compatibility.


Configuring IIS

After you have installed or upgraded IIS, you'll have a Web server. At this point, it's important to configure your Web server even if you've upgraded. Windows Server 2003's IIS has many new features that you'll want to take advantage of.

IIS can be configured through the Internet Information Services snap-in, which you can access in Start, Administrative Tools.

Using the IIS Snap-in

There are many Web services components that need to be configured to optimize IIS for security, functionality, and redundancy. The IIS snap-in, shown in Figure 11.3, is the interface in which you administer the IIS services. In the left pane of the snap-in, you can find the following folders:

Figure 11.3. IIS services administration window.

[View full size image]

  • Application Pools Application pools are sections of physical memory that are dedicated to the applications that run within a pool. Application pools segment applications from the rest of the memory resources used by other IIS services. This promotes higher reliability and security, but it also requires more memory configured on the Web server. As the name implies, the DefaultAppPool is created by default.

  • Web Sites This folder contains all the Web sites that are being hosted on the Web server. The Default Web Site is created by default.

  • Web Service Extensions Web Service extensions are services that comprise the IIS Web server. For instance, depending on your installation method and choices, you may have FrontPage Server Extensions and ASP.NET services loaded. Each of the services that you see listed can either be allowed or prohibited to run on the Web server. This is illustrated in Figure 11.4.

Figure 11.4. Web Service Extensions window.

[View full size image]

Configuring Web Services

As mentioned earlier, IIS can support up to 10,000 Web sites on a single Web server. The number of Web sites that you have depends on the way the system is configured, including the number of processors, the amount of RAM, bandwidth, and more. For every Web site that the system supports for the Internet, there must be a public IP address and registered domain name. However, if you have only one public IP address and you want to support other Web sites, you can also create virtual directories to have those sites serving users on the Internet.

Using virtual directories is a sound option to support more than one Web site on a single IP address, but keep in mind that users from the Internet will use a subdirectory from your Web site to reach a separate Web site. For instance, a company hosting http://www.companyabc.com decides to host another Web site using a virtual directory; in this case, users would connect to http://www.companyabc.com/NewWebSite/ to be able to connect to the second Web site.

Creating a Web Site with IIS

The Default Web Site is located within the Web Sites folder in the IIS snap-in. You can use the default Web site for your own Web site, but it is best that you create and configure a separate Web site.

To begin creating a new Web site, do the following:

1. | Right-click Web Sites. Then select New, Web Site, or if you have the new Web site already created and located in an XML file, you can select Web Site (From File). This second option prompts you to locate an XML file to load.
2. | If you choose the latter approach, the Web Site Creation Wizard starts. Click Next to continue.
3. | Type in the description of the Web site and click Next to continue.
4. | The following screen presents network-related choices such as the IP address to use for this site, the TCP port, and the Host Header for the Web site. Complete this information and click Next to continue.
5. | Enter the home directory to use (or click the Browse button) and allow or deny anonymous access to this site. Click Next to continue.
6. | At this point, set the permissions on the home directory. Select from read, run scripts, execute, write, and browse permissions. Click Next to continue.
7. | Click Finish.

Selecting Web Site Properties

Right-clicking Web Sites or the Default Web Site in the snap-in and then selecting Properties gives you options for globally modifying the default settings for a Web site. However, right-clicking a specific Web site gives more options for configuring only that Web site. For simplicity, this section will describe the default Web site settings.

The Default Web Site Properties page, shown in Figure 11.5, has some of the tabs for configuring a Web site. From here, you can control everything from identification to specific filtering. These options are as follows:

Figure 11.5. Default Web Site Properties page.

  • Web Site tab This tab has three characteristics including identification, connections, and logging. Here, you can identify the Web site with a name, IP address, and TCP and SSL ports. Also, you can set timeout values for connections as well as logging options. Logging is enabled by default using the W3C Extended Log File Format.

  • Performance tab This tab, shown in Figure 11.6, has two options that allow you to control bandwidth to this site in terms of kilobytes per second (KBps) and limiting the number of simultaneous connections. The first option is used to control bandwidth so that one Web site doesn't consume all the bandwidth that may negatively affect other Web sites. Limiting the number of connections allows the Web site to keep response times within acceptable values.

  • ISAPI Filters tab ISAPI filters are programs that respond to certain events during HTTP request processing. You can add, enable, and disable filters for a Web site on this tab.

  • Home Directory tab A home directory is the top-level directory for a Web site. It is created for the Default Web Site and you must specify one for each additional Web site. This tab, shown in Figure 11.7, also has configuration settings for Web site applications, such as read, write, browsing, script source access, indexing, and application logging. In addition, you can assign other application settings, including execute permissions and application pool membership.

  • Documents tab Within the Documents tab, you can define the Web site's default Web page as well as enable document footers. Document footers can be appended to each Web page in the Web site.

  • Directory Security tab The Directory Security tab, shown in Figure 11.8, offers anonymous access and authentication control, IP address and domain name restrictions, and secure communications configuration options. From here, you can define who has access, how they get authenticated, and whether communications must be secure. These options are examined in the "Securing IIS" section later in this chapter.

  • HTTP Headers tab This tab manages the Web site's content. Although you can't create content for the Web site, you can define content expiration, customize HTTP headers, edit content ratings, and configure additional multipurpose Internet mail extensions (MIME) types.

  • Custom Errors tab Within the Custom Errors tab, there are numerous HTTP error messages. You can create or edit any of these messages to provide customization for your Web site.

Figure 11.6. Performance tab bandwidth configuration options.

Figure 11.7. Web site home directory and application configuration options.

Figure 11.8. Directory Security tab.

One other tab, called Service, appears only after you right-click the Web Sites folder and select Properties. On this tab, you can set IIS isolation mode to run as an IIS 5 isolation mode server. Also, you can set HTTP compression on application files as well as static files to save bandwidth. This tab is shown in Figure 11.9.

Figure 11.9. HTTP compression settings.

Creating and Configuring a Virtual Directory

Virtual directories extend the home directory of your Web site by providing an alias linking another directory not contained within the home directory. This alias will appear to users as simply a subfolder to the Web site even though it may be located on an entirely different server.

The virtual directory can contain documents and other information for the Web site as well as a new Web site. For example, if CompanyABC's Web site (http://www.companyabc.com) wants to host a temporary Web site for another organization, it could use a virtual directory to contain the Web site. In this scenario, CompanyXYZ would have its own Web site located at http://www.companyabc.com/companyxyz/.

To create a virtual directory using the IIS Manager, do the following:

1. | Right-click the Web site that you want to create a virtual directory for and select New, Virtual Directory. After the Virtual Directory Creation Wizard appears, click Next to continue.
2. | Enter the virtual directory's alias and click Next.
3. | Specify the path containing the information or Web site and click Next.
4. | Choose the access privileges (read, run scripts, execute, write, or browse) for the virtual directory and click Next.
5. | Click Finish.

Similar to Web site properties, a virtual directory has properties pages that allow you to set specific options. Figure 11.10 illustrates the virtual directory properties pages. You'll notice that there is a smaller subset of configuration options for a virtual directory in comparison to a Web site.

Figure 11.10. Virtual directory properties page.

There are five configuration tabs including Virtual Directory, Documents, Directory Security, HTTP Headers, and Custom Errors. The tabs represent and are applied to the virtual directory but are similar to the configuration tabs for the Web site.


Configuring and Optimizing Applications

Web sites can operate only as well as the Web applications installed on the systems. Therefore, IIS's many improvements have been to support those applications to run as efficiently as possible. Improving how Web applications can interact with IIS also improves Web server reliability and availability.

Application Isolation and Pooling

IIS supports two modes of application isolation: worker process isolation mode and IIS 5 isolation mode. Both modes of operation use Http.sys and application pooling. Application pools are queues for requests within Http.sys and one or more worker processes. Applications are assigned to an application pool based on their URL, and many pools can run at the same time. For example, by default, DefaultAppPool is located within the Application Pools folder.

On a given Web site there may be only one mode of operation working to support the Web applications. It is recommended to use worker process isolation mode exclusively unless there is a specific compatibility issue with a particular application. Using worker process mode gives the greatest boost to reliability and availability. Another reason to use worker process isolation mode is that the type of application isolation that is in use causes IIS to dynamically adjust internal architecture parameters to accommodate the fundamental differences between the two isolation modes.

The IIS 5 isolation mode is used primarily to support applications that may depend on features in earlier versions (mainly IIS 5) of IIS. It's important to use this isolation mode only when the application cannot work properly under the worker process isolation mode. Otherwise, this mode can increase the resource requirements needed to run such applications when compared to worker process mode. This could, in turn, affect performance and reliability of the system.

Note

New installations of IIS 6 automatically use worker process isolation mode. Upgrades to IIS 6 from previous versions (IIS 4 and 5) use IIS 5 isolation mode. If there are no known compatibility issues, the isolation mode can be changed to worker process isolation mode after installation.

IIS 6 Process Recycling

Generally speaking, Web sites are expected to be up and running without little interruption. Moreover, these Web sites must adequately service user requests. Sites that require this level of service must incorporate fault tolerance into the infrastructure's design. For example, many Web servers must be linked together by some form of network load balancing to ensure minimal downtime.

Even the most reliable Web sites must have the servers refreshed at some point so that the applications can be recycled or other maintenance can occur. Another solution that can work in conjunction with infrastructure fault tolerance is using IIS 6 process recycling. Using IIS 6 minimizes the number of server refreshes that may be required because of its capability to automatically refresh Web applications without affecting the rest of the system or stopping service to that Web application. Process recycling is also extremely useful for those Web applications that can be problematic because the server must be restarted. Often it is difficult to rewrite an application to work better because of budgetary reasons, technical limitations, or extensive effort required to make the changes.

Within the Properties Recycling tab of an application pool such as the one shown in Figure 11.11, applications can be recycled every so many minutes (the default is 1,740 minutes or 29 hours), after a set number of requests to that application, at a specified time, or when a certain amount of physical or virtual memory is used.

Figure 11.11. Application recycling configurations.

When one of these events occurs, one of two procedures can happen:

  • Another worker process will be created by Web Administration Services and the old process terminates. This process, called overlapping recycling, ensures that requests aren't dropped even though a process is being recycled.

  • The current process terminates, and WAS creates a new process immediately thereafter.

Process recycling is a welcomed feature; however, it doesn't apply to every situation. For obvious reasons, process recycling doesn't work on static content, but it also doesn't work if the Web site uses custom-built ISAPI applications. Also, if session state data is required on the Web site, it's important to be aware that session state data may be lost during process recycling.

Monitoring IIS Health

Using IIS to monitor applications is now feasible with IIS 6. More specifically, WAS can perform the following health-monitoring procedures:

  • Ping worker processes after a specified period of time.

  • Monitor for failed applications and disable the application pool after a certain number of failures or a set number of failures within a given time frame.

When a worker process doesn't respond to a ping, WAS can terminate the worker process and create another one so that the application can keep servicing requests.

Application Performance

There are many variables with how applications perform. They include, but aren't limited to, the server resources, the way the application is written, and the way the environment is structured.

Process recycling and health detection help ensure that applications are running efficiently and effectively. Another set of features is located under the Performance tab of the application pool properties page. Within the Performance tab are options specifically geared toward optimizing performance, including the following:

  • Idle Timeout Applications can be shut down after being idle for a specified period of time. A timeout value of 20 minutes is enabled by default.

  • Kernel Requests Queues Kernel Requests queues can be limited to a certain number of requests. This option is enabled with a default value of 1,000 outstanding requests.

  • CPU Utilization CPU utilization for an application pool can be limited so that the pool doesn't consume CPU time unnecessarily. This option is disabled by default. If it is enabled, an action can be performed after CPU utilization is exceeded.

  • Web Gardens Under the Web Gardens option, a maximum number of worker processes can be set.

Application Options

Numerous application types are supported on IIS, including, but not limited to, Active Server Pages, ASP.NET, COM+, Java, Common Gateway Interface (CGI), and FastCGI. No matter what types of applications the server will host, it's imperative to adequately test them. You should test the applications under various workloads and consider using those that are specifically designed to run on the IIS platform. For instance, ASP and ASP.NET were developed solely for IIS and can therefore perform much better than other technologies that weren't built for a specific platform.


Installing and Configuring FTP Services

FTP is one of several utilities bundled within TCP/IP, and it is an accepted means to transfer files to and from remote computers. Unlike previous IIS versions of FTP, the service includes FTP user isolation and isn't installed by default with IIS.

To install FTP, perform the following steps:

1.
Double-click Add or Remove Programs within the Control Panel.

2.
In the Add or Remove Programs dialog box, click Add/Remove Windows Components.

3.
Within the Windows Components Wizard, scroll down and then highlight Application Server.

4.
Click Details, and then in the Application Server window, shown in Figure 11.12, highlight IIS.

Figure 11.12. IIS Web application server settings.

5.
Click Details again and then select File Transfer Protocol (FTP) Service.

6.
Click OK twice.

7.
Click Next and wait for Windows Server 2003 to install FTP.

8.
Click Finish when you're done.

Isolating FTP Users for Content Protection

IIS now can isolate FTP users so that FTP content is protected. This is an especially useful feature for ISPs and ASPs servicing a large number of users. Each FTP user can have his own separate directory in which to upload and download files to the Web or FTP server. As users connect, they see only their directory as the top-level directory and can't browse other FTP directories. Permissions can be set on the FTP home directory to allow create, modify, or delete operations.

FTP user isolation is based on an FTP site rather than at the server level and is either enabled or disabled. However, sites that need to enable FTP user isolation aren't forced to strictly use this feature. You can enable anonymous access in conjunction with FTP user isolation by creating a virtual directory within the FTP site and allowing read-only access. The only limitation to mixing the FTP user isolation and anonymous access is that information can be downloaded only from the public or read-only virtual directory.

Note

FTP user isolation and Active Directory can be used together where an AD container (not the entire AD) can be used to authenticate users and isolate them from other FTP directories. In this scenario, it is extremely important to thoroughly lock down the FTP server and communications. For example, it is recommended to use either IPSec or SSL to secure communications when using AD and FTP user isolation.

FTP user isolation is enabled during the creation of the FTP site. When you reach the user isolation page, select Isolate Users and follow the remaining prompts. You'll notice a warning message stating that after isolation is enabled, you can't switch the site to non-isolation.

Creating an FTP Site

By default, the Default FTP Site is created and enabled. However, to create a new FTP site (in addition to the Default FTP Site), do the following:

1. | Right-click on the FTP Sites folder and select New, FTP Site. You can also select FTP Site (From File) if you have an XML file for an FTP site creation.
2. | In the FTP Site Creation Wizard, click Next and then provide a description for the FTP site. Click Next to continue.
3. | Set the IP address and port for FTP to use. By default, FTP uses port 21. Click Next to continue.
4. | In the next window, select the appropriate FTP user isolation setting. You can choose from not isolating users, isolating users with local accounts on the Web server, or isolating users using Active Directory. Click Next to continue. Note FTP user isolation settings can't be changed after initial configuration.
5. | Specify the path to the FTP home directory and then click Next.
6. | Set permissions to the FTP site (read or write access) and click Next to continue.
7. | Click Finish.

FTP Properties Page

As you can see in Figure 11.13 and Figure 11.14, you can access two separate properties pages for FTP. The first properties page appears after you right-click the FTP Sites folder. The second properties page is for a specific FTP site.

Figure 11.13. FTP Sites Properties page.

Figure 11.14. FTP configuration settings.

The FTP Sites folder properties page is used to configure global properties for FTP sites. If multiple FTP sites are created, these settings will be the default configurations for the sites.

Within the FTP Sites folder properties are the following configuration tabs:

  • FTP Site tab This configuration tab has limited functionality. FTP site connections and logging configuration parameters can be set here.

  • Security Accounts tab This tab allows you to configure authentication with anonymous accounts and user accounts. Unchecking the default Allow Anonymous Connections option, as shown in Figure 11.15, brings up a warning window stating that passwords may be vulnerable while transmitting across a network unless encryption or SSL is used. Selecting Yes allows you to continue. However, you can't set up the accounts, encryption, or SSL from this tab.

  • Messages tab FTP messages can be displayed as users connect or disconnect from the FTP site. From a security perspective, your organization may require a warning message such as

    Use of this FTP Site is by permission only. All uploads and downloads must adhere
to the data transmission policies of Company ABC.

    In addition, messages can be displayed when a user can't connect because of a maximum user limitation such as

    You have been disconnected because a maximum user limit has been reached. Please
try again later.

    Messages are not required; they are intended to help the users of the FTP site.

  • Home Directory tab Similar to the Web Site Home Directory tab, the FTP Home Directory tab can be used to set permissions on the FTP site directory. The style of the directory listing (either Unix or MS-DOS) can be set. The MS-DOS setting is the default.

  • Directory Security tab Under this tab, TCP/IP access restrictions can be set based on the IP address. IP addresses or groups of IP addresses can be granted or denied access to the FTP directories.

Figure 11.15. Security Accounts configuration tab.

The differences between the FTP Sites folder properties and a specific Web site are minimal. The following tabs in the FTP site properties are different:

  • FTP Site tab The difference with this tab is your ability to set descriptions and define an IP address and port for the site.

  • Home Directory tab This tab allows you to set the location for FTP content.


Examining Optional IIS Components

IIS now forces the administrator to consider each and every option before installing a component. This way, the administrator can avoid unnecessary security risks by not installing unnecessary components or services that might lead to vulnerabilities if not kept in close watch. With regard to optional IIS components, most components are optional. However, several services are considered separate entities although they are a part of IIS. These services are SMTP Service, NNTP Service, and Indexing.

SMTP Services

The Simple Mail Transport Protocol Service is a messaging service that allows email messages to be sent from the Web server. In essence, the IIS Web server can also be an email server. To install the SMTP Service, do the following:

1.
Double-click Add or Remove Programs within the Control Panel.

2.
In the Add or Remove Programs dialog box, click Add/Remove Windows Components.

3.
Within the Windows Components Wizard, scroll down and then highlight Application Server.

4.
Click Details, and then in the Application Server window, highlight IIS.

5.
Click Details again and then select SMTP Service, as shown in Figure 11.16.

Figure 11.16. SMTP Services configuration options.

6.
Click OK twice.

7.
Click Next and wait for Windows Server 2003 to install the SMTP Service.

8.
Click Finish when you're done.

NNTP Service

IIS can host internal or external newsgroups through the use of the NNTP Service. Newsgroups are still a popular way to extend communications to a large audience. The newsgroups can be used for a variety of tasks, including sharing information and data.

The News Service provides newsgroups using the Network News Transport Protocol, which is the protocol responsible for managing the messages for each newsgroup. It's unlike mass emailing, though, because the messages are exchanged either server-to-server or client-to-server, never server-to-client. In the first scenario (server-to-server), messages can be exchanged between two NNTP servers. A common example is an internal NNTP server requesting messages from an external server from an ISP. Clients can subscribe (and unsubscribe) to newsgroups to read and post messages.

An NNTP server requires additional disk and network capacity due to the high disk space utilization and potentially high bandwidth requirements. To install a news server, you can follow the same procedures as you did installing the SMTP server, except you need to select the NNTP Service rather than the SMTP Service.

Indexing Internet Services

Indexing is a Windows Server 2003 component that has been separated from IIS. If this service is installed on the Web server, all content can be indexed to provide faster search results of Web-based information.

Tip

Many people wonder how to search for content in Adobe Acrobat PDF files located on a Web site. The Indexing Service provided with Windows Server 2003 doesn't provide this functionality, but a driver located on Adobe's support site provides this functionality for free. Visit http://support.adobe.com and search for iFilter.


Securing IIS

There shouldn't be any question that IIS is significantly more secure than its predecessors. Several key enhancements such as a reduced attack surface and enhanced application isolation deliver a robust and secure Web platform. IIS also is enabled by default to present only static information (that is, to use applications or other dynamic content, you must manually enable them).

However, Microsoft products are also the most popular products to try to hack. For this reason, it's important to secure the Web server as much as possible. The more barriers there are, the less inclined a hacker would be to try to gain unauthorized access. Each component on the Web server must be secure; the server is as secure as its weakest point.

Windows Server 2003 Security

Windows Server 2003 security actually begins during the planning and designing phases so that every conceivable security aspect is addressed. This can entail physical, logical (Windows Server 2003, applications, and so on), and communications security.

When you're securing the Windows Server 2003 Web server, it's important to use NTFS on the disk subsystem and apply the latest service pack and security patches. Using NTFS is critical because it can have appropriate permissions set on files, folders, and shares. Also, keeping up to date with service packs and patches ensures that Windows Server 2003 is operating with the greatest amount of protection.

Application security on the Windows Server 2003 Web server should be carefully reviewed, especially if it's a custom-built application. If the application is developed by a vendor, make sure that you have an application that is certified to run on Windows Server 2003 and that the latest service packs and patches have been applied and tested.

Note

For more information on securing Windows Server 2003, refer to Part IV, "Security."

Locking Down Web Service Extensions

As mentioned earlier, IIS can display only static content (.htm, image files, and so on) by default until you manually enable dynamic content. IIS gives granular control over the dynamic content. For example, you can enable Active Server Pages but disable ASP.NET applications.

To enable or disable dynamic information, do the following:

1. | In the IIS Manager, expand the Web server name and select Web Service Extensions.
2. | In the Web Service Extensions window on the right, select the extensions you want to configure and click on either Allow or Prohibit.

Using the Web Service Extensions interface, you can also add and allow extensions for specific applications that may not be already listed.

IIS Authentication

Authentication is a process that verifies that users are who they say they are. IIS supports a multitude of authentication methods, including the following:

  • Anonymous Users can establish a connection to the Web site without providing credentials.

  • Integrated Windows authentication This authentication method can be integrated with Active Directory. As users log on, the hash value of the password is sent across the wire instead of the actual password.

  • Digest authentication Similar to Integrated Windows authentication, a hash value of the password is transmitted. Digest authentication requires a Windows Server 2003 domain controller to validate the hash value.

  • Basic authentication Basic authentication sends the username and password over the wire in clear text format. This authentication method offers little security to protect against unauthorized access.

  • .NET Passport authentication .NET Passport is a Web authentication service developed by Microsoft. It doesn't reside on the hosting Web server but rather is a central repository contained and secured by Microsoft that allows users to create a .NET Passport account once. This username and password can be used at any .NET Passportenabled site. For more information on .NET Passport, refer to Chapter 14, "Windows Server 2003 Passports."

These authentication methods can be enabled under the Authentication Methods dialog box, as illustrated in Figure 11.17. You can view this window by clicking the Edit button located on the Directory Security tab of a Web site properties page.

Figure 11.17. Authentication Methods settings.

Auditing Web Services

Windows Server 2003 auditing can be applied to Web and FTP sites to document attempts to log on (successful and unsuccessful), to gain unauthorized access to service accounts, to modify or delete files, and to execute restricted commands. These events can be viewed through the Event Viewer. It's also important to monitor IIS logs in conjunction with audited events to determine how, when, and if external users were trying to gain unauthorized access.

Using SSL Certificates

Secure Sockets Layer preserves user and content integrity as well as confidentiality so that communications from a client and the Web server, containing sensitive data such as passwords or credit card information, are protected. SSL is based on the public key security protocol that protects communication by encrypting data before being transmitted.

Previous versions of IIS could use SSL, and IIS 6 is no different. The exception to this, though, is how SSL is implemented within IIS. The version implemented within Windows Server 2003's IIS has the following improvements:

  • SSL's performance is up to 50% faster than previous implementations. SSL has been streamlined so that resource requirements aren't as high.

  • SSL can now be remotely managed from a centralized location.

  • A greater number of SSL hardware devices is now supported in Windows Server 2003. These hardware devices (such as smart cards, bio-informatic controllers, and so on) offload some of the resource requirements from Windows Server 2003.

SSL certificates serve three primary purposes, although they are typically used to encrypt connections. These purposes include the following:

  • SSL server authentication This allows a client to validate a server's identity. SSL-enabled client software can use a public key infrastructure (PKI) to check whether a server's certificate is valid. It can also check whether the certificate has been issued by a trusted certificate authority (CA).

  • SSL client authentication This allows a server to validate a client's identity. SSL can validate that a client's certificate is valid as well as check whether the certificate is from a trusted CA.

  • Encrypting SSL connections The most common application of SSL is encrypting all traffic on a given connection. This provides a high degree of confidentiality and security.

Note

SSL puts little strain on bandwidth but can significantly increase processor utilization. To minimize the performance impact that SSL can have on a given system, consider using a hardware-based SSL adapter to offload the workload from the computer's processors.

From an IIS perspective, SSL can be applied to an entire Web site, directories, or specific files within the Web site. SSL configuration can be done through the IIS snap-in located on the Start, Administrative Tools menu.

To use SSL on a Web site, it must first be requested and then installed. The request can be created to obtain a certificate either from an external, trusted CA or from an internal PKI. To request a SSL certificate for a Web site, do the following:

1. | Open the Internet Information Services (IIS) Manager snap-in and expand the desired computer, Web sites folder, and the Web site to assign the certificate.
2. | Right-click on the Web site and select Properties.
3. | On the Directory Security tab, select Server Certificate.
4. | Click Next on the Web Server Certificate Wizard Welcome screen.
5. | Click the Create a New Certificate button and click Next.
6. | Select the Prepare the Request Now, But Send It Later option and then click Next.
7. | Enter the new certificate name and choose the desired bit length for the encryption key. It is recommended to use 1024 (the default) or higher as the bit length. Keep in mind that higher bit lengths can decrease performance. Click Next when done.
8. | Type in the company and organization unit name and then click Next.
9. | Type the name of the IIS computer hosting the Web site in the Common Name box. If the site will be accessed from the Internet, enter in the fully qualified domain name such as server.domain.com. The common name should match the URL users will use to connect to the Web site. Click Next to continue.
10. | Select a Country/Region from the first pull-down menu and then type in the State/Province and City/Locality that will be embedded in the certificate. Click Next to continue.
11. | Provide a path and filename for the certificate request and then click Next.
12. | Review the Request File Summary to ensure that all information is accurate. Click Next and then click Finish to complete the request.

After the certificate has been requested, it must be submitted to a trusted CA to process. To submit the newly created certificate request to an internal CA, do the following:

1.
Open a browser and enter the following URL of the server that is hosting Certificate Services (for example, http://servername/certsrv).

2.
If a sign-in dialog box appears, enter a username and password with sufficient privileges to generate the certificate and click OK.

3.
Select Request a Certificate.

4.
On the next page, select Advanced Certificate Request.

5.
Select Submit a Certificate Request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

6.
On the Submit a Certificate Request or Renewal Request page, click the Browse for a File to Insert link or manually enter the text within the certificate request file you just created.

7.
Within the Certificate Template section, use the pull-down menu to select Web Server as shown in Figure 11.18. Click the Submit button when done.

Figure 11.18. Submitting a certificate request.

[View full size image]

8.
On the Certificate Issued page, select the Download Certificate link and when prompted click Save to then be able to specify a path and filename for the certificate.

To apply the SSL certificate, do the following:

1. | Open the IIS Manager snap-in and navigate to the Web site for which the certificate was created.
2. | Right-click on the Web site and select Properties.
3. | Click on the Directory Security tab and click the Server Certificate button.
4. | Click Next on the initial Server Certificate Wizard window, and then select Process the Pending Request and Install the Certificate. Click Next to continue.
5. | Locate the certificate file that was created in the previous steps and then click Next.
6. | On the SSL Port window, type in the listening port for SSL (443 is the default) and then click Next.
7. | Review the summary information and then click Next. Click Finish if the information is correct; otherwise, click the Back button or submit a new request.

Configuring FTP Security Options

FTP is, by default, an unsecured protocol. It's unsecured due to the method of user authentication and the transfer of the data. For example, if users need to supply a username and password, the information can be captured and easily read because the information is transmitted in clear text.

Many organizations have abandoned using FTP for supplying read-only downloads to external users. In this scenario, organizations are using HTTP instead to provide downloads. Securing HTTP is much simpler than FTP and doesn't require as much administration.

Securing FTP Transfer

FTP transfer can be secured using encryption via a VPN connection (such as IPSec and L2TP). Typically, this presents unnecessary obstacles and burdens to end users. Users would have to establish a VPN connection before they could download files, which may become a technical challenge for many users.

Securing FTP Authentication

Without a secure connection between the end user supplying a username and password and the FTP server, it is impossible to adequately secure FTP. Usernames and passwords could potentially be compromised if a hacker were to capture FTP traffic to the server. As a result, FTP security would be more protected if the FTP server allows only anonymous connections. This way, users won't have to supply usernames and passwords.

Other FTP Security Measures

Some other possible ways to minimize FTP security risks are the following:

  • Use local folders to share downloads and secure them with NTFS. The folder should be located on a separate partition from Windows Server 2003 system files.

  • Offer read-only content to users.

  • Monitor disk space and IIS logs to ensure that a hacker isn't attempting to gain unauthorized access.


Maintaining IIS

The IIS metabase is an information store that contains all IIS configurations. As such, it's important to maintain the IIS metabase to ensure the utmost reliability of the IIS server. Otherwise, a disaster could potentially cause unnecessary downtime or the inability to fully recover IIS and corresponding configurations.

The IIS metabase is no longer a proprietary information store. It is now an XML-based hierarchical store that contains configuration and schema information. As a result, the IIS metabase can be modified while it is running (that is, IIS services do not necessarily have to be stopped and restarted for changes to take effect). This feature is very useful to promote reliability and availability, but this functionality must be used with care; otherwise, a configuration change may cause failures. As a result, it's important to keep backups up to date.

Note

The ability to edit the metabase while running is not turned on by default. To enable this feature in the IIS Manager, right-click on server, select Properties, and then select Enable Direct Metabase Edit.

Windows Server 2003 automatically backs up the IIS metabase. However, you can back up the IIS metabase by using the IIS Manager as well as by using a backup product such as Windows Server 2003's Backup utility. To perform a manual backup using the IIS Manager, perform the following steps:

1.
Click Start, Programs, Administrative Tools, Internet Information Services (IIS) to start the IIS Manager.

2.
Select the Web server in the left pane.

3.
Select Backup/Restore Configuration from the Action, All Tasks menu.

4.
In the Configuration Backup/Restore window, you can see a listing of automatic backups that IIS has already performed. Click the Create Backup button to perform a manual backup.

5.
Specify the name of the backup in the dialog box and check the check box if this backup will be encrypted using a password, as illustrated in Figure 11.19.

Figure 11.19. IIS backup configuration options settings.

6.
Click OK and then Close.

Backups are stored in the %SystemRoot%\System32\Inetsrv\MetaBack folder by default. It is also important to note that the IIS metabase can be imported and exported to an XML file.

IIS Logging

IIS logging should be viewed as a necessity rather than an optional feature of IIS. Logging helps to ensure IIS security and is also a great maintenance and troubleshooting function. Reviewing logs gives you intimate details of what is going on in the system. This information can then be used to review maintenance procedures and identify problems in the system.

IIS text-based logging, such as the W3C Extended Log File Format, Microsoft IIS Log File Format, and NCSA Common Log File Format, is controlled by Http.sys, a kernelmode process. This is a change from previous versions in which logging was a user-mode process. The other log file format, ODBC, is implemented using a user-mode worker process.

Note

To enable this feature in the IIS Manager, right-click on server, select Properties, and then select Enable Direct Metabase Edit.


Internet Explorer Enhanced Security Configuration for Servers

It goes without saying that the Internet Explorer (IE) browser complements the capabilities of IIS. These feature sets, and the system it runs on, however, are what needs to be protected. As part of Microsoft's security initiative, IE on the Windows Server 2003 platforms are now more secure.

The IE Enhanced Security Configuration is set on all server-based Windows Server 2003 editions. The first screen you notice after starting IE is an informational page about the security configuration as shown in Figure 11.20.

Figure 11.20. The IE Enhanced Security Configuration default page.

[View full size image]

IE Enhanced Security Configuration protects the system by using IE's security zones. The Internet zone is set to high, trusted zones are set to medium-level security, and any local intranet zone remains at a medium-low setting. These settings restrict which Web sites can be browsed. When trying to visit a non-trusted site, a window pops up warning you that the Web site is not on the trusted list of sites (see Figure 11.21). However, you can grant access to any site by adding the site to the list of trusted sites. To add the site from the window illustrated in Figure 11.21, click the Add button. You will be prompted to then add the URL to the list of trusted sites. Alternatively, you can also add sites manually from a list, apply them to specific users or groups of users, or lower the security zone settings within IE's options.

Figure 11.21. Security zone warning window.

Although the warning pop-up windows can get annoying, it does help serve the purpose of protecting the server system. As Microsoft states in the IE Enhanced Security Configuration documentation, it is important to keep Web browsing on a server system to a minimum and when you do visit Web sites be sure that they can be trusted. Using IE on servers to visit Web sites should be used to obtain information for troubleshooting, downloading the latest update, and the like.


Summary

IIS 6 is a major improvement over previous versions in terms of security, reliability, availability, and performance. These facets have been a top priority for Microsoft. Microsoft has incorporated both internal and customer-based feedback to provide a robust platform for providing Web services.


Best Practices

  • Use IIS 6 to improve performance and strengthen security.

  • Thoroughly design and plan the IIS 6 environment.

  • Define the goals and objectives of the IIS 6 project.

  • Identify and review IIS application types and requirements.

  • Define security requirements to meet the goals and objectives.

  • Balance the security methodologies to be used with the associated risks and end user experience.

  • Examine and design disaster recovery plans, and monitor requirements and maintenance practices.

  • Document the current IIS infrastructure and the IIS design decisions.

  • Build fault tolerance into the Web infrastructure based on how much downtime can be afforded and existing SLAs.

  • Use IIS 5 isolation mode only to provide compatibility for applications that rely on features in earlier versions of IIS that cannot work in IIS 6 isolation mode.

  • Use IIS 6 process recycling to provide additional fault tolerance and minimize the number of server refreshes.

  • Use IIS to monitor applications such as pinging worker processes after a specified period of time, monitoring for failed applications, and disabling the application pool after a certain number of failures or a set number of failures within a given time frame.

  • Isolate FTP users so that FTP content is protected.

  • Provide search capabilities for Adobe Acrobat PDF file content on a Web site by using the iFilter driver.

  • Use NTFS on the disk subsystem, and apply the latest service pack and security patches to begin securing the IIS system.

  • Carefully review application security on the Windows Server 2003 Web server, especially if using a custom-built application.

  • Choose an authentication method carefully depending on business and technical requirements.

  • Apply auditing to Web and FTP sites to document attempts to log on (successful and unsuccessful), to gain unauthorized access to service accounts, to modify or delete files, and to execute restricted commands.

  • Use SSL to ensure confidentiality.

  • Use IPSec and L2TP to secure FTP.

  • Use local folders to share downloads, and secure them with NTFS. The folder should be located on a separate partition from Windows Server 2003 system files.

  • Monitor disk space and IIS logs to ensure that a hacker isn't attempting to gain unauthorized access.

  • Turn on the ability to edit the metabase while running.

  • Use logging not only to review IIS security but also to assist with maintenance and troubleshooting.


Part IV: Security

In This Part

CHAPTER 12 Server-Level Security

CHAPTER 13 Transport-Level Security

CHAPTER 14 Windows Server 2003 Passports

CHAPTER 15 Security Policies and Tools


Chapter 12. Server-Level Security

In This Chapter

  • Defining Windows Server 2003 Security

  • Deploying Physical Security

  • Hardening Server Security

  • Using Security Templates to Secure a Server

  • File-Level Security

  • Additional Security Mechanisms

  • Using Windows Server Update Services


Defining Windows Server 2003 Security

The term Microsoft security was long considered, whether fairly or unfairly, to be an oxymoron. High-profile vulnerabilities and viruses that were exploited in Windows NT and Windows 2000 often made organizations wary of the security, or lack of security, that was built into Microsoft technologies. In direct response to this criticism, security in Windows Server 2003 became the major, if not the most important, priority for the development team. Subsequent revisions of Windows Server 2003, such as Service Pack 1 and R2, have taken security even further as well.

Security on the server level is one of the most important considerations for a network environment. Servers in an infrastructure not only handle critical network services, such as DNS, DHCP, directory lookups, and authentication, but they also serve as a central location for most, if not all, critical files in an organization's network. Subsequently, it is important to establish a server-level security plan and to gain a full understanding of the security capabilities of Windows Server 2003.

This chapter focuses on the server-side security mechanisms in Windows Server 2003. Particular emphasis is placed on the importance of keeping servers up to date with security patches through such enhancements as Software Update Services, a major improvement to Windows security. In addition, file-level security, physical security, and other critical server security considerations are presented.

Microsoft's "Trustworthy Computing" Initiative

On the heels of several high-profile viruses and security holes, Bill Gates developed what became known as the "Trustworthy Computing" initiative. The basics of the initiative boiled down to an increased emphasis on security in all Microsoft technologies. Every line of code in Windows Server 2003 was combed for potential vulnerabilities, and the emphasis was shifted from new functionality to security. What the initiative means to users of Microsoft technology is the fact that security has become a major priority for Microsoft, and Windows Server 2003 is the first major release that takes advantage of this increased security emphasis.

Common Language Runtime

All Microsoft code is verified through a process called common language runtime. It processes application code and automatically checks for security holes that can be caused by mistakes in programming. In addition, it scrutinizes security credentials that are used by specific pieces of code, making sure that they perform only those actions that they are supposed to. Through these techniques, the common language runtime effectively reduces the overall threat posed to Windows Server 2003 by limiting the potential for exploitations and vulnerabilities.

The Layered Approach to Server Security

Security works best when it is applied in layers. It is much more difficult to rob a house, for example, if a thief not only has to break through the front door, but also has to fend off an attack dog and disable a home security system. The same concept applies to server security: Multiple layers of security should be applied so that the difficulty in hacking into a system becomes exponentially greater.

Windows Server 2003 seamlessly handles many of the security layers that are required, utilizing Kerberos authentication, NTFS file security, and built-in security tools to provide for a great deal of security right out of the box. Additional security components require that you understand their functionality and install and configure their components. Windows Server 2003 makes the addition of extra layers of security a possibility, and positions organizations for increased security without sacrificing functionality.


Deploying Physical Security

One of the most overlooked but perhaps most critical components of server security is the actual physical security of the server itself. The most secure, unbreakable Web server is powerless if a malicious user can simply unplug it. Worse yet, someone logging into a critical file server could potentially copy critical data or sabotage the machine directly.

Physical security is a must for any organization because it is the most common cause of security breaches. Despite this fact, many organizations have loose levels, or no levels, of physical security for their mission-critical servers. An understanding of what is required to secure the physical and login access to a server is consequently a must.

Restricting Physical Access

Servers should be physically secured behind locked doors, in a controlled-access environment. It is unwise to place mission-critical servers at the feet of administrators or in similar, unsecure locations. Rather, a dedicated server room or server closet that is locked at all times is the most ideal environment for the purposes of server security.

Most hardware manufacturers also include mechanisms for locking out some or all of the components of a server. Depending on the other layers of security deployed, it may be wise to utilize these mechanisms to secure a server environment.

Restricting Login Access

All servers should be configured to allow only administrators to physically log in to the console. By default, such use is restricted on domain controllers, but other servers such as file servers, utility servers, and the like must specifically forbid these types of logins. To restrict login access, follow these steps:

1.
Choose Start, All Programs, Administrative Tools, Local Security Policy.

2.
In the left pane, navigate to Security Settings\Local Policies\User Rights Assignment.

3.
Double-click Allow Log On Locally.

4.
Remove any users or groups that do not need access to the server, as illustrated in Figure 12.1. (Keep in mind that, on Web servers, the IUSR_SERVERNAME account will need to have log on locally access to properly display Web pages.) Click OK when finished.

Figure 12.1. Restricting login access.

Note

If you replace Local Security Policy in the restriction lockdown instructions in step 1 with Domain Security Policy, you will be able to carry out these same instructions on a Windows Server 2003 domain controller.

Note

A Group Policy set on an OU level can be applied to all servers, simplifying this task and negating the need to perform it manually on every server. For more information on setting up these types of Group Policies, refer to Chapter 21, "Windows Server 2003 Group Policies."

Using the Run As Command for Administrative Access

Logging off administrators after using any and all workstations and servers on a network is often the most difficult and tedious security precaution. If an administrator forgets, or simply steps away from a workstation temporarily without logging out, any persons passing by can muck around with the network infrastructure as they please.

For this reason, it is wise to consider a login strategy that incorporates the Run As command that is embedded in Windows Server 2003. Essentially, this means that all users, including IT staff, log in with restricted, standard User accounts. When administrative functionality is required, IT support personnel can invoke the tool or executable by using the Run As command, which effectively gives that tool the administrative capabilities of the account that were designated by Run As. If an administrator leaves a workstation console without logging out, the situation is not critical because the console will not grant a passerby full administrator access to the network.

The following example illustrates how to invoke the Computer Management MMC snap-in using the Run As command from the GUI interface:

1.
Navigate to (but do not select) Start, All Programs, Administrative Tools, Computer Management.

2.
Right-click Computer Management in the program list and then choose Run As.

3.
In the Run As dialog box, shown in Figure 12.2, choose the credentials under which you want to run the program and click OK.

Figure 12.2. Using the Run As command.

Note

A command-line version of the Run As tool allows for the same type of functionality. For example, the following syntax opens the command-prompt window with administrator access:

runas /user:DOMAINNAME\administrator cmd

In addition to the manual method of using Run As, an administrator's desktop can be configured to have each shortcut automatically prompt for the proper credentials upon entering an administrative tool. For example, the Active Directory Users and Computers MMC snap-in can be set to permanently prompt for alternate credentials by following these steps:

1.
Choose Start, All Programs, Administrative Tools.

2.
Right-click Computer Management and choose Properties.

3.
Click the Advanced button.

4.
Check the Run with Different Credentials box, as shown in Figure 12.3, and click OK twice to save the settings.

Figure 12.3. Running a shortcut with alternate credentials.

Note

Ironically, administrative access is sometimes required to be able to change some of the shortcut properties. Consequently, you might need to log in as a user with higher privileges to set up the shortcuts on other users' profiles.

Using Smartcards for Login Access

The ultimate in secured infrastructures utilize so-called smartcards for login access; these smartcards are fully supported in Windows Server 2003. A smartcard is a credit cardsized piece of plastic with an encrypted microchip embedded within. Each user is assigned a unique smartcard and an associated PIN. Logging in to a workstation is as straightforward as inserting the smartcard into a smartcard reader and entering in the PIN, which can be a combination of numbers and letters, similar to a password.

Security can be raised even higher by stipulating that each smartcard be removed after logging in to a console. In this scenario, users insert into the smartcard reader a smartcard that is physically attached to their person via a chain or string. After entering their PIN, they log in and perform all necessary functions. Upon leaving, they simply remove the smartcard from the reader, which automatically logs them off the workstation. In this scenario, it is nearly impossible for users to forget to log out because they must physically detach themselves from the computer to leave.

Securing Wireless Networks

Wire security has always been an issue, but recent trends toward wireless networks have made it even more so. Most organizations are shocked to see what kind of damage can be done to a network simply by a person being able to connect via a network port. The addition of wireless networks makes access even easier; for example, an unsavory individual can simply pull up in the parking lot and access an organization's LAN via a laptop computer and a standard 8s02.11b wireless card. The standard security employed by wireless networks, WEP, is effectively worthless because it can be cracked in several minutes.

Controlling the network ports and securing network switches are part of the securing strategy. For organizations with wireless networks, more stringent precautions must be taken. Deployment of wireless networks using the 802.1x protocol vastly increases the security of the mechanism. Microsoft uses 802.1x to secure its vast wireless network, and Windows Server 2003 fully supports the protocol.

For those organizations without the time or resources to deploy 802.1x, the simple step of placing wireless access points outside the firewall and requiring VPN access through the firewall can effectively secure the wireless network. Even if trespassers were to break the WEP key, they would be connected only to an orphaned network, with no place to go.

Firewall Security

Deployment of an enterprise firewall configuration is a must in any environment that is connected to the Internet. Servers or workstations directly connected to the Internet are prime candidates for hacking. Modern firewall implementations such as Microsoft's Internet Security and Acceleration (ISA) 2000/2004 offer advanced configurations, such as Web proxying and DMZ configuration, as well. Proper setup and configuration of a firewall in between a Windows Server 2003 network and the Internet are a must.

Note

Installing ISA Server 2000 on Windows Server 2003 is technically possible but can be difficult. The installation will complete (with several error messages), but it is important to apply ISA Service Pack 1 immediately after installation on a Windows Server 2003 system. On the other hand, the newest version, ISA Server 2004, natively supports installation on Windows Server 2003.


Hardening Server Security

Previous versions of Windows Server 2003, such as Windows NT 4.0 and Windows 2000, often required a great deal of configuration after installation to "harden" the security of the server and ensure that viruses and exploits would not overwhelm or disable the server. The good news with Windows Server 2003 is that, by default, many less commonly used services are turned off. In fact, the entire Internet Information Services (IIS) 6.0 implementation on every server is turned off by default, making the actual server itself much less vulnerable to attack.

Subsequently, in Windows Server 2003, it is important to first define which roles a server will utilize and then to turn on only those services as necessary, and preferably with the use of the Configure Your Server Wizard, which will be explained in depth in the "Securing a Server Using the Configure Your Server Wizard" section in this chapter.

Defining Server Roles

Depending on the size of an organization, a server may be designated for one or multiple network roles. In an ideal world, a separate server or servers would be designated to handle a single role, such as DHCP server or DNS server. This scenario is not feasible for smaller organizations, however, and multiple roles can be placed on a single server, as defined by the needs of the organization.

Because any service that is activated increases the overall risk, it is important to fully define which roles a server will take on so that those services can be properly configured. Although these components can be set up manually, the process of turning on these services is streamlined through the use of the Configure Your Server Wizard.

Securing a Server Using the Configure Your Server Wizard

With the list of roles that a server will perform in hand, the ideal utility for turning on these roles and securing them is the newly renovated Configure Your Server (CYS) Wizard in Windows Server 2003. Vastly improved over the Windows 2000 version, the new CYS Wizard turns on only those services that are necessary. If a server is a DNS server but does not do File and Print, the CYS Wizard will automatically configure the server specifically for DNS access, limiting its vulnerability.

The Configure Your Server Wizard is straightforward to use, and can be invoked at any time. In addition to installing future services, the CYS Wizard will also display the current roles of an operating server. The CYS Wizard is used to establish a server as a dedicated WINS server, thus limiting its security exposure by shutting off all other unnecessary roles. The following steps detail the process:

1.
Open the CYS Wizard (Start, All Programs, Administrative Tools, Configure Your Server Wizard).

2.
Click Next twice at the Welcome and Preliminary screens. CYS will then detect the current network settings.

3.
On the subsequent screen, select the WINS server role, as illustrated in Figure 12.4, and click Next.

Figure 12.4. Running the Configure Your Server Wizard.

[View full size image]

4.
At the Summary screen, click Next to continue. Setup may ask for the Windows Server 2003 CD at this point. Insert the CD as prompted.

5.
Click Finish at the Success screen.

6.
Repeat steps 15, except instead of adding a role, select the file server role to remove it. Click Next to continue.

Note

You must run the CYS Wizard multiple times to add or remove any additional roles.


Using Security Templates to Secure a Server

Windows Server 2003 contains built-in support for security templates, which can help to standardize security settings across servers and aid in their deployment. A security template is simply a text file that is formatted in such a way that specific security settings are applied uniformly. For example, the security template could force a server to use only Kerberos authentication and not attempt to use downlevel (and less secure) methods of authentication. Figure 12.5 illustrates one of the default templates included in Windows Server 2003, the securedc.inf template file.

Figure 12.5. A sample security template file.

[View full size image]

The application of a security template is a straightforward act and can be accomplished by applying a template directly to an OU, a site, or a domain via a Group Policy Object (GPO). Security templates can be enormously useful in making sure that all servers have the proper security applied, but they come with a very large caveat. Often, the settings defined in a template can be made too strict, and application or network functionality can be broken by security templates that are too strong for a server. It is therefore critical to test all security template settings before deploying them to production.

Shutting Off Unnecessary Services

Each service that runs, especially those that use elevated system privileges, poses a particular security risk to a server. Although the security emphasis in Windows Server 2003 reduces the overall threat, there is still a chance that one of these services will provide entry for a specialized virus or determined hacker. Subsequently, a great deal of effort has been put into the science of determining which services are necessary and which can be disabled. Windows Server 2003 simplifies this guessing game with an enhanced Services MMC snap-in. To access the Services console, choose Start, All Programs, Administrative Tools, Services.

As evident in Figure 12.6, the Services console not only shows which services are installed and running, but also gives a reasonably thorough description of what each service does and the effect of turning it off. It is wise to audit the Services log on each deployed server and determine which services are necessary and which can be disabled. Finding the happy medium is the goal because too many running services could potentially provide security holes, whereas shutting off too many services could cripple the functionality of a server.

Figure 12.6. Using the Services console to administer the server.

[View full size image]

Note

Windows Server 2003 Service Pack 1 introduced the Security Configuration Wizard, which streamlines the ability of administrators to intelligently disable unneeded services and apply security settings to a server. Although it doesn't replace traditional securing techniques, it increases the amount of securing methods available.


File-Level Security

Files secured on Windows Server 2003 are only as secure as the permissions that are set on them. Subsequently, it is good to know that Windows Server 2003, for the first time in a Microsoft operating system, does not grant the Everyone group full control over share-level and NTFS-level permissions. In addition, critical operating system files and directories are secured to disallow their unauthorized use.

Despite the overall improvements made, a complete understanding of file-level security is recommended to ensure that the file-level security of a server is not neglected.

NT File System Security

The latest revision of the NT File System (NTFS) is used in Windows Server 2003 to provide for file-level security in the operating system. Each object that is referenced in NTFS, which includes files and folders, is marked by an Access Control Entry (ACE) that physically limits who can and cannot access a resource. NTFS permissions utilize this concept to strictly control read, write, and other types of access on files.

File servers should make judicious use of NTFS-level permissions, and all directories should have the file-level permissions audited to determine if there are any holes in the NTFS permission-set. Changing NTFS permissions in Windows Server 2003 is a straightforward process; simply follow these steps:

1.
Right-click the folder or file onto which the security will be applied and choose Sharing and Security.

2.
Select the Security tab.

3.
Click the Advanced button.

4.
Uncheck the Allow Inheritable Permissions from the Parent to Propagate box.

5.
Click Remove when prompted about the application of parent permissions.

6.
While you're in the Advanced dialog box, use the Add buttons to give access to the groups and/or users who need access to the files or folders.

7.
Check the Replace Permission Entries on All Child Objects box, as illustrated in Figure 12.7, and click OK.

Figure 12.7. Setting NTFS permissions.

[View full size image]

8.
When prompted about replacing security on child objects, click Yes to replace child object security and continue.

9.
Click OK to close the property page.

Share-Level Security Versus NTFS Security

Previous Windows security used share-level permissions, which were independently set. A share is a file server entry point, such as \\sfofs01\marketing, that allows users access to a specific directory on a file server. Older file systems such as FAT, HPFS, and FAT32 did not include file-level security, so the security was set instead on the share level. While sharelevel security can still be set on files, it is preferable to use NTFS-level security, where possible. Share-level security is not very secure because it cannot secure the contents of subdirectories easily.

Note

A common best practice for file servers in Windows Server 2003 is to configure share-level security to be wide open for all domain users but then to set stricter security on the NTFS level. This allows for security to be administered on the NTFS level only, without the fear of share-level restrictions interfering.

Auditing File Access

A good practice for file-level security is to set up auditing on a particular server, directory, or file. Auditing on NTFS volumes allows administrators to be notified of who is accessing, or attempting to access, a particular directory. For example, it may be wise to audit access to a critical network share, such as a finance folder, to determine whether anyone is attempting to access restricted information.

Note

Audit Entries are another example of security settings that can be automatically set via security templates in Windows Server 2003. It is wise to consider the use of security templates to more effectively control audit settings.

The following steps illustrate how to set up simple auditing on a folder in Windows Server 2003:

1.
Right-click the folder or file onto which the auditing will be applied and choose Properties.

2.
Select the Security tab.

3.
Click the Advanced button.

4.
Select the Auditing tab.

5.
Uncheck the Allow Inheritable Auditing Entries from the Parent to Propagate box and click Apply.

6.
Using the Add button, enter all users and groups that will be audited. If you're auditing all users, enter the Everyone group.

7.
In the Auditing property page, select all types of access that will be audited. If you're auditing for all success and failure attempts, select all the options, as indicated in Figure 12.8.

Figure 12.8. Selecting what to audit.

8.
Click the OK button to apply the settings.

9.
Check the Replace Auditing Entries on All Child Objects box and click OK twice to save the settings.

Note

An effective way of catching "snoops" in the act is to create serious-looking shares on the network, such as Financial Statements, Root Info, or similar such shares, and audit access to those folders. This technique has been successfully used to identify internal (or external) saboteurs before they could do some serious damage.

Encrypting Files with the Encrypting File Service

Windows Server 2003 continues support for the Encrypting File System (EFS), a method of scrambling the contents of files to make them unintelligible to unauthorized users. EFS has proven to be valuable for organizations that desire to keep proprietary data, especially those stored on laptops, out of the wrong hands.

Windows 2000 supports EFS, but it was not until the release of Windows XP that EFS saw strong use as it became accessible through the Windows Explorer menus. From the server side, however, EFS was limited because offline files stored on file servers could not be encrypted. Windows Server 2003 improves upon this design, offering support for offline files to be encrypted via EFS. This added functionality makes EFS a valuable addition to the server-side security available in Windows Server 2003.


Additional Security Mechanisms

In an insecure world, a server is only as secure as the software that runs on it. Windows Server 2003 is the most secure Windows yet, and includes many built-in mechanisms to keep a server secure. Additional security considerations such as antivirus options and backup should be taken into account, however, as they directly affect the overall security of the operating system itself.

Antivirus Precautions

Viruses may be one of the most dangerous threats faced by servers. Many viruses are written to specifically exploit key vulnerabilities that are present in server infrastructure. Others infect files that may be held on a server, spreading the infection to clients who download files. Consequently, it is extremely important to consider the use of an enterprise antivirus solution on all file servers in a network. All the major antivirus manufacturers include robust file-level scanners, and file servers should consider using them.

An aggressive plan should be in place to keep antivirus patterns and engines up to date. Because virus outbreaks can wreak havoc worldwide in a matter of hours, rather than days, it is wise to have servers check for updates daily.

Note

It is not necessary or wise to enable an always-on antivirus scanner on non-file servers. These types of scanners continually scan all open files that are in use and are best used only on file servers or workstations. Although including periodic scans of system components on other servers is not a bad idea, the fact that utility servers or domain controllers do not physically store user data keeps them relatively free from the effect of file-level viruses. In addition, the processor utilization of these always-on virus scanners can affect the performance of these servers.

Deploying Backup Security

Although the need for a backup strategy may seem obvious to most people, it is often surprising to find out how inadequately prepared many organizations are in regard to their backups. All too often, a company will discover that it is very easy to back up a server but often more difficult to restore. In addition to disaster recovery issues, the issue of backup security is often neglected.

File server backups require that an authenticated user account with the proper privileges copy data to a storage mechanism. This requirement ensures that not just anyone can back up an environment and run off with the tape. Keeping this point in mind, the tapes that contain server backups should be protected with the same caution given to the server itself. All too often, a big pile of server backup tapes is left out on unsecured desks, and there is often no mechanism in place to account for how many tapes are in which location. Implementing a strict tape retention and verification procedure is subsequently a must.


Using Windows Server Update Services

One of the main drawbacks to Windows security has been the difficulty in keeping servers and workstations up to date with the latest security fixes. For example, the security fix for the Index Server component of IIS was available for more than a month before the Code Red and Nimbda viruses erupted onto the scene. If the deployed Web servers had downloaded the patch, they would not have been affected. The main reason that the vast majority of the deployed servers were not updated was that keeping servers and workstations up to date with the latest security patches was an extremely manual and time-consuming process. For this reason, a streamlined approach to security patch application was required and realized with the release of Software Update Services (SUS) and its subsequent and newer iterations, Windows Server Update Services (WSUS).

Understanding the Background of WSUS: Windows Update

In response to the original concerns regarding the difficulty in keeping computers properly patched, Microsoft made available a centralized Web site called Windows Update to which clients could connect, download security patches, and install them. Invoking the Windows Update Web page remotely installed an executable, which ran a test to see which hotfixes had been applied. Those that were not applied were offered up for download, and users could easily install these patches.

Windows Update streamlined the security patch verification and installation process, but the major drawback was that it required a manual effort to go up to the server every few days or weeks and check for updates. A more efficient, automated process was required.

Deploying the Automatic Updates Client

The Automatic Updates Client was developed to automate the installation of security fixes and patches and to give users the option to automatically "drizzle" patches across the Internet to the local computer for installation. Drizzling, also known as Background Intelligent Transfer Service (BITS), is a process in which a computer intelligently utilizes unused network bandwidth to download files to the machine. Because only unused bandwidth is used, there is no perceived effect on the network client itself.

The Automatic Updates Client was included as a standard feature that is installed with Windows 2000 Service Pack 3 and Windows XP Service Pack 1. It is also available for download as a separate component.

Understanding the Development of Windows Server Update Services

The Windows Update Web site and the associated client provided for the needs of most home users and some small offices. However, large organizations, concerned about the bandwidth effects of downloading large numbers of updates over the Internet, often disabled this service or discouraged its use. These organizations often had a serious need for Windows Update's capabilities. This fact led to the development of Software Update Services, which was later improved into the new product, Windows Server Update Services.

WSUS is a free download from Microsoft that effectively gives organizations their own, independent version of the Windows Update server. WSUS runs on a Windows Server 2003 machine that is running Internet Information Services. Clients connect to a central intranet WSUS server for all their security patches and updates.

WSUS is not considered to be a replacement technology for existing software deployment solutions such as Systems Management Server (SMS), but rather it is envisioned as a solution for mid- to large-size businesses to take control over the fast deployment of security patches as they become available. Current SMS customers may decide instead to use the SMS 2.0 Value Pack, which includes security-patch functionality similar to that offered by WSUS.

WSUS Prerequisites

Deploying WSUS on a dedicated server is preferable, but it can also be deployed on a Windows Server 2003 member server, as long as that server is running Internet Information Services. The following list details the minimum levels of hardware on which WSUS will operate:

  • 700MHz x86-compatible processor

  • 512MB RAM

  • 6GB available disk space

In essence, a WSUS server can easily be set up on a workstation-class machine, although more enterprise-level organizations might desire to build more redundancy in to a WSUS environment.

In addition to these hardware requirements, WSUS also requires the installation of IIS 5.0 or greater and Background Internet Transfer Service (BITS) 2.0 or greater.

Installing a Windows Server Update Services System

The installation of WSUS is straightforward, assuming that IIS has been installed and configured ahead of time (for more information on installing IIS, refer to Chapter 11, "Internet Information Services v6"). The executable for WSUS can be downloaded from the WSUS Web site at Microsoft, currently located at the following URL:

http://www.microsoft.com/wsus

To complete the initial installation of WSUS, follow these steps:

1.
Run the WSUS Setup from the CD or the download executable.

2.
Click Next at the Welcome screen.

3.
Review and accept the license agreement to continue. Click Next to continue.

4.
Select to store updates locally and accept the default location. Click Next to continue.

5.
Select to install the SQL Desktop engine on the computer, and click Next.

6.
Select to use the existing IIS Web site, as shown in Figure 12.9. Click Next to continue.

Figure 12.9. Installing WSUS.

[View full size image]

7.
Do not check to inherit settings from a different server, as shown in Figure 12.10. Check this only if an existing WSUS server exists from which settings should be copied. Click Next to continue.

Figure 12.10. Reviewing WSUS installation settings.

[View full size image]

8.
Click Next after reviewing the settings on the Ready to Install dialog box.

9.
The installation will complete and the admin Web site URL will be displayed after you click Finish.

The administration Web page (http://servername/WSUSAdmin) will be automatically displayed after installation. This page is the main location for all configuration settings for WSUS and is the sole administrative console. By default, it can be accessed from any Web browser on the local network. All further configuration will take place from the Admin console, as illustrated in Figure 12.11.

Figure 12.11. Viewing the WSUS Admin Console.

[View full size image]

Setting WSUS Options

After installation, WSUS will not physically contain any security patches. The first task after installation should be configuring all the options available to the server. You can invoke the option page by clicking Options in the upper pane of the WSUS Admin page.

The Options page in WSUS allows you to set specific settings such as Synchronization Options, Automatic Approval Options, and Computer Options (refer to Figure 12.11). These options provide for critical information such as how often the server will synchronize itself, whether a proxy server will be used, and how to manage computer groups.

Synchronizing a WSUS Server

After configuring all the options in WSUS, particularly the options regarding which security patch languages will be supported, the initial synchronization of the WSUS server can take place. To perform the synchronization, follow these steps:

1.
Open the WSUS Admin Web page by launching Internet Explorer on the WSUS server and going to http://localhost/WSUSAdmin.

2.
Click the Synchronize Now link in the main pane.

3.
The next screen to be displayed, shown in Figure 12.12, gives you the option of synchronizing with the WSUS site now or setting up a synchronization schedule. It is advised to do a full WSUS synchronization first and to schedule subsequent downloads on a daily basis thereafter. So, in this example, click the Synchronize Now button.

Figure 12.12. Setting WSUS synchronize server options.

[View full size image]

4.
An updated WSUS catalog will then be downloaded in addition to all the security patches that exist on the corporate WSUS server. Downloading may take a significant amount of time, depending on the Internet connection in use.

Note

Plan to run the initial synchronization of WSUS over a weekend, beginning the download on Friday evening. Given the number of security patches that you will need to download and the overall Internet connection bandwidth consumption used, it is wise to limit the impact that this procedure will have on the user population.

Approving WSUS Software Patches

After the initial synchronization has taken place, all the relevant security patches will be downloaded and ready for approval. Even though the files are now physically downloaded and in the IIS metadirectory, they cannot be downloaded by the client until the approval process has been run on each update. This allows administrators to thoroughly test each update before it is approved for distribution to corporate servers and workstations. To run the approval process, follow these steps:

1.
Open the WSUS Admin Web page by launching Internet Explorer on the WSUS server and going to http://localhost/WSUSAdmin.

2.
Click the Updates link in the top pane.

3.
Select all updates that will be approved (you can select multiple ones and click the Change Approval link, as shown in Figure 12.13).

Figure 12.13. Approving updates.

[View full size image]

Depending on the number of updates downloaded, the preceding steps may need to be repeated several times before all updates are approved.

4.
From the drop-down box, select Install and click OK.

5.
Select to replace any existing approvals, and click OK.

6.
The updates will then be approved.

Note

A good approach to testing updates is to download them first on a client with direct access to Windows Update on the Internet. After the test server or workstation has successfully downloaded and all functionality has been verified, that particular security patch can be approved in WSUS for the rest of the corporate clients.

Automatically Configuring Clients via Group Policy

As previously mentioned, the Automatic Updates client can be downloaded from Microsoft and deployed on managed nodes in an environment, either manually or through automated measures. Service Pack 3 for Windows 2000 includes the client by default, as well as Service Pack 1 for Windows XP. After the client is installed, it can be configured to point to a WSUS server, rather than the default Internet Windows Update location.

The configuration of each client can be streamlined by using a Group Policy in an Active Directory environment. Windows Server 2003 domain controllers automatically contain the proper Windows Update Group Policy extension, and a Group Policy can be defined by following these steps:

1.
Open Active Directory Users and Computers (Start, All Programs, Administrative Tools, Active Directory Users and Computers).

2.
Right-click the organizational unit that will have the Group Policy applied and click Properties.

3.
Select the Group Policy tab.

4.
Click the New button and name the Group Policy.

5.
Click the Edit button to invoke the Group Policy Object Editor.

6.
Expand the Group Policy Object Editor to Computer Configuration\Administrative Templates\Windows Components\Windows Update, as illustrated in Figure 12.14.

Figure 12.14. Configuring Windows Update Group Policy settings.

[View full size image]

7.
Double-click the Configure Automatic Updates setting.

8.
Set the Group Policy to be enabled, and configure the automatic updating sequence as desired. The three options given2, 3, and 4allow for specific degrees of client intervention. For seamless, client-independent installation, choose option 4.

9.
Schedule the interval that updates will be installed, bearing in mind that some updates require reboots.

10.
Click Next Setting to configure more options.

11.
Click Enabled to specify the Web location of the WSUS server. Entering the fully qualified domain name is recommended, as indicated in Figure 12.15. Enter both settings (usually the same server) and click OK to save the Group Policy settings.

Figure 12.15. Setting the WSUS server location via a Group Policy.

12.
Repeat the procedure for any additional organizational units. (The same Group Policy can be used more than once.)

Note

Organizations that do not use Active Directory or Group Policies have to manually configure each client's settings to include the location of the WSUS server. This can be done through a local policy or manually through Registry settings, as defined in the WSUS Help.

Tip

A useful trick for automating the testing of new WSUS patches is to deploy two WSUS servers and two sets of Group Policies. The first WSUS server serves as a pilot WSUS server, and all updates are approved as soon as they become available. A subset of the client population then points to this server through a GPO and installs the patches immediately. After the patch has been validated on this pilot group, the real WSUS server can then be set to approve the patch, deploying the update to the rest of the user population. This model requires more hardware resources but streamlines the WSUS update process.

Deploying Security Patches with WSUS

Depending on the settings chosen by the Group Policy or the Registry, the clients that are managed by WSUS will automatically download updates and install them on clients at a specified time. Some computers may be configured to allow for local interaction, scheduling proper times for the installation to take place and prompting for "drizzle" downloading.

Clients that are configured to use WSUS will not be prompted to configure their Automatic Update settings, and they will be grayed out to prevent any changes from occurring. Users without local administrative access will not be able to make any changes to the installation schedule, although local admin users will be able to postpone forced installs.

Note

Generally, it is good practice to allow servers to control the download and installation schedule, but to force clients to do both automatically. Depending on the political climate of an organization, this may or may not be a possibility.


Summary

Out of the box, Windows Server 2003 is by far the most secure Windows yet. Increased security emphasis through the Trustworthy Computing initiative helps to increase overall server security by disabling unnecessary services and locking out file-level permissions by default. In addition to the standard features, advanced options in Windows Server 2003 allow administrators to add multiple layers of security to servers, further protecting them from attacks and vulnerabilities. In addition, the automatic updating capabilities of tools such as Software Update Services give organizations an edge in protecting servers and workstations from constantly changing security threats.


Best Practices

  • Physically secure servers behind locked doors, in a controlled-access environment.

  • Apply security in layers.

  • Use Configure Your Server Wizard (CYS) for turning on server roles and securing them.

  • Use the Security Configuration Wizard included in Windows Server 2003 SP1 and R2 to reduce a server's attack surface.

  • Use the Run As command when administrative access is required instead of logging in as an Administrator.

  • Identify internal (or external) saboteurs before they can do some serious damage by creating serious-looking shares on the network, such as Financial Statements, Root Info, or similar such shares, and audit access to those folders.

  • Don't enable always-on antivirus scanning on non-file servers. Instead, run periodic scans.

  • Plan to run the initial synchronization of WSUS over a weekend, beginning the download on Friday evening.

  • Test and approve WSUS patches before deploying them to production, either manually or through a process of setting up a pilot WSUS server and a production WSUS server.


Chapter 13. Transport-Level Security

In This Chapter

  • Introduction to Transport-Level Security in Windows Server 2003

  • Virtual Private Networks

  • Public Key Infrastructure

  • Using IPSec Encryption with Windows Server 2003

  • Configuring Simple IPSec Between Servers in a Windows Server 2003 Domain


Introduction to Transport-Level Security in Windows Server 2003

In the past, networks were closed environments, insulated from each other and accessible only on internal segments. After time, a need developed to share information between these networks, and connections were established to transmit data from network to network. The transmission of this information was originally insecure, however, and, if intercepted, could easily be read by unauthorized persons. The need to secure this information was subsequently made a priority, and became a critical component of network infrastructure.

Over time the technology used to keep this information safe evolved along with the technology available to exploit and obtain unauthorized access to data. Despite these threats, intelligent design and configuration of secure transport solutions using Windows Server 2003 will greatly increase the security of a network. In many cases, they are absolutely required, especially for data sent across uncontrolled network segments, such as the Internet.

This chapter focuses on the mechanisms that exist to protect and encrypt information sent between computers on a network. New and improved transport security features in Windows Server 2003 are highlighted, and sample situations are detailed. IPSec, PKI, and VPN use is outlined and illustrated. In addition, specific server functionality such as that provided by Windows Server 2003's Routing and Remote Access Server and Internet Authentication Server components is presented.

The Need for Transport-Level Security

The very nature of interconnected networks requires that all information be sent in a format that can easily be intercepted by any client on a physical network segment. The data must be organized in a structured, common way so that the destination server can translate it into the proper information. This simplicity also gives rise to security problems, however, because intercepted data can easily be misused if it falls into the wrong hands.

The need to make information unusable if intercepted is the basis for all transport-level encryption. Considerable effort goes into both sides of this equation: Security specialists develop schemes to encrypt and disguise data, and hackers and other security specialists develop ways to forcefully decrypt and intercept data. The good news is that encryption technology has developed to the point that properly configured environments can secure their data with a great deal of success, as long as the proper tools are used. Windows Server 2003 offers much in the realm of transport-level security, and deploying some or many of the technologies available is highly recommended to properly secure important data.

Security Through Multiple Layers of Defense

Because even the most secure infrastructures are subject to vulnerabilities, deploying multiple layers of security on critical network data is recommended. If a single layer of security is compromised, the intruder will have to bypass the second or even third level of security to gain access to the vital data. For example, relying on a complex 128-bit "unbreakable" encryption scheme is worthless if an intruder simply uses social engineering to acquire the password or PIN from a validated user. Putting in a second or third layer of security, in addition to the first one, will make it that much more difficult for intruders to break through all layers.

Transport-level security in Windows Server 2003 uses multiple levels of authentication, encryption, and authorization to provide for an enhanced degree of security on a network. The configuration capabilities supplied with Windows Server 2003 allow for the establishment of several layers of transport-level security.

Note

Security through multiple layers of defense is not a new concept, but is rather adapted from military strategy, which rightly holds that multiple lines of defense are better than one.

Encryption Basics

Encryption, simply defined, is the process of taking intelligible information and scrambling it so as to make it unintelligible for anyone except the user or computer that is the destination of this information. Without going into too much detail on the exact methods of encrypting data, the important point to understand is that proper encryption allows this data to travel across unsecured networks, such as the Internet, and be translated only by the designated destination. If packets of properly encrypted information are intercepted, they are worthless because the information is garbled. All mechanisms described in this chapter use some form of encryption to secure the contents of the data sent.


Virtual Private Networks

A common method of securing information sent across unsecured networks is to create a virtual private network (VPN), which is effectively a connection between two private nodes or networks that is secured and encrypted to prevent unauthorized snooping of the traffic between the two connections. From the client perspective, a VPN looks and feels just like a normal network connection between different segments on a networkhence the term virtual private network.

Data that is sent across a VPN is encapsulated, or wrapped, in a header that indicates its destination. The information in the packet is then encrypted to secure its contents. The encrypted packets are then sent across the network to the destination server, using what is known as a VPN tunnel.

VPN Tunnels

The connection made by VPN clients across an unsecured network is known as a VPN tunnel. It is named as such because of the way it "tunnels" underneath the regular traffic of the unsecured network.

VPN tunnels are logically established on a point-to-point basis but can be used to connect two private networks into a common network infrastructure. In many cases, for example, a VPN tunnel serves as a virtual WAN link between two physical locations in an organization, all while sending the private information across the Internet. VPN tunnels are also widely used by remote users who log in to the Internet from multiple locations and establish VPN tunnels to a centralized VPN server in the organization's home office. These reasons make VPN solutions a valuable asset for organizations, and one that can be easily established with the technologies available in Windows Server 2003 or extended even further with technologies that integrate directly with Windows Server 2003 VPN technology, such as the Internet Security and Acceleration (ISA) Server 2004 product.

Note

VPN tunnels can either be voluntary or compulsory. In short, voluntary VPN tunnels are created when a client, usually out somewhere on the Internet, asks for a VPN tunnel to be established. Compulsory VPN tunnels are automatically created for clients from specific locations on the unsecured network, and are less common in real-life situations than are voluntary tunnels.

Tunneling Protocols

The tunneling protocol is the specific technology that defines how data is encapsulated, transmitted, and unencapsulated across a VPN connection. Varying implementations of tunneling protocols exist, and correspond with different layers of the Open System Interconnection (OSI) standards-based reference model. The OSI model is composed of seven layers, and VPN tunneling protocols use either Layer 2 or Layer 3 as their unit of exchange. Layer 2, a more fundamental network layer, uses a frame as the unit of exchange, and Layer 3 protocols use a packet as a unit of exchange.

The most common Layer 2 VPN protocols are the Point-to-Point Tunneling Protocol (PPTP) and the Layer 2 Tunneling Protocol (L2TP), both of which are fully supported protocols in Windows Server 2003.

PPTP and L2TP Protocols

Both PPTP and L2TP are based on the well-defined Point-to-Point Protocol (PPP) and are consequently accepted and widely used in VPN implementations. L2TP is the preferred protocol for use with VPNs in Windows Server 2003 because it incorporates the best of PPTP, with a technology known as Layer 2 Forwarding. L2TP allows for the encapsulation of data over multiple network protocols, including IP, and can be used to tunnel over the Internet. The payload, or data to be transmitted, of each L2TP frame can be compressed, as well as encrypted, to save network bandwidth.

Both PPTP and L2TP build on a suite of useful functionality that was introduced in PPP, such as user authentication, data compression and encryption, and token card support. These features, which have all been ported over to the newer implementations, provide for a rich set of VPN functionality.

L2TP/IPSec Secure Protocol

Windows Server 2003 uses an additional layer of encryption and security by utilizing IP Security (IPSec), a Layer 3 encryption protocol, in concert with L2TP in what is known, not surprisingly, as L2TP/IPSec. IPSec allows for the encryption of the L2TP header and trailer information, which is normally sent in clear text. This also has the added advantage of dual-encrypting the payload, adding an additional level of security into the mix.

L2TP/IPSec has some distinct advantages over standard L2TP, namely the following:

  • L2TP/IPSec allows for data authentication on a packet level, allowing for verification that the payload was not modified in transit, as well as the data confidentiality that is provided by L2TP.

  • Dual-authentication mechanisms stipulate that both computer-level and user-level authentication must take place with L2TP/IPSec.

  • L2TP packets intercepted during the initial user-level authentication cannot be copied for use in offline dictionary attacks to determine the L2TP key because IPSec encrypts this procedure.

An L2TP/IPSec packet contains multiple, encrypted header information and the payload itself is deeply nested within the structure. This allows for a great deal of transport-level security on the packet itself.

Administering a VPN Using an Internet Authentication Service Server

Users who connect via a VPN connection need to be authenticated through a mechanism that stores the users' associated username and password information in a centralized location. Traditional VPN solutions utilized a directory on a Remote Authentication Dial-in User Service (RADIUS) server, which authenticated users based on their remote access usernames and passwords. Often, however, these user accounts were different from the domain user accounts, and administration of the two environments was complicated because multiple passwords and user accounts needed to be administered.

Windows Server 2003 simplifies the VPN authentication process by utilizing the Internet Authentication Service (IAS) installed on a Windows Server 2003 server to provide for RADIUS-based authentication of users using domain Active Directory usernames and passwords.

You can install and configure IAS on a Windows Server 2003 server by following these steps:

1.
Choose Start, Control Panel, Add or Remove Programs.

2.
Click Add/Remove Windows Components.

3.
Select the Networking Services component (don't check it) and click the Details button.

4.
Check the Internet Authentication Service box, as illustrated in Figure 13.1, and click OK.

Figure 13.1. Installing IAS.

5.
Click Next to continue. The installation will proceed.

6.
Click Finish at the Completion screen.

Depending on the administrative credentials used to install IAS, you may need to register it in Active Directory following installation if it will be used to authenticate users who exist in AD for VPN and dial-up access. To perform this function, follow these steps:

1. | Choose Start, All Programs, Administrative Tools, Internet Authentication Service.
2. | Right-click Internet Authentication Service (Local) and choose Register Server in Active Directory. Note Domain membership is required for the option to register the server in Active Directory to be displayed. If the server is not a member of the domain, the Register Server option will be grayed out.
3. | If IAS was already registered in AD, acknowledgment of that fact will be displayed. Otherwise, a success dialog box will be displayed, indicating the proper registration of IAS with AD.

Using Routing and Remote Access Service to Establish VPNs

The Routing and Remote Access Server (RRAS), available for installation on Windows Server 2003, effectively provides servers with VPN functionality through the use of L2TP/IPSec and PPTP authentication. RRAS servers can be established to serve on one end or on both ends of a VPN conversation, and work in concert with IAS to authenticate VPN users.

RRAS in Windows Server 2003 adds key functionality such as network load balancing (NLB) support and increased performance; it also integrates the Internet Connection Firewall (ICF) component into RRAS.

Note

While Windows Server 2003 contains robust VPN support, additional VPN functionality can be obtained by extending Windows Server 2003 with the Internet Security and Acceleration (ISA) Server 2004/2006 product available from Microsoft. ISA Server extends the RRAS Service to allow for rule-based access control and application layer inspection of VPN traffic. For more information, reference Sams Publishing's ISA Server 2004 Unleashed and/or ISA Server 2006 Unleashed titles.

The Routing and Remote Access Server can be installed on a Windows Server 2003 computer by using the Configure Your Server (CYS) Wizard, as described in the following steps:

1.
Open the Configure Your Server Wizard (Start, All Programs, Administrative Tools, Configure Your Server Wizard).

2.
Click Next at the Welcome screen.

3.
Click Next at the Preliminary Steps screen. CYS will then check the network settings of the server.

4.
Select Remote Access/VPN Server, as illustrated in Figure 13.2, and click Next to continue.

Figure 13.2. Installing the RRAS component.

[View full size image]

5.
At the Summary screen, click Next to continue. CYS will then install the component and automatically invoke the RRAS Setup Wizard.

6.
Click Next at the RRAS Setup Wizard Welcome screen.

7.
The subsequent screen is critical because you can define specific RRAS functionality. RRAS can be set up for remote access VPN or VPN with Network Address Translation (NAT) access. In addition, it can be set up as one end of a VPN between two private networks. Finally, a custom configuration can be chosen, as illustrated in Figure 13.3. In this example, choose Remote Access and click Next to continue.

Figure 13.3. Choosing RRAS options.

[View full size image]

8.
Check the VPN box at the following screen and click Next to continue.

Note

If two network adapters are not installed in the server you are creating for the VPN setting, the wizard will prompt to choose the custom configuration option where a single network adapter can be configured for this setup.

9.
At the finalization screen, click Finish to finalize the RRAS settings chosen.

10.
A final confirmation box will indicate that RRAS has been installed and will ask whether the service should be started. Click Yes to start the service and complete the installation and then click Finish to close the CYS Wizard.

The RRAS server is the key to implementing the VPN options described in this chapter and can be used to provide for any of the options listed here.


Public Key Infrastructure

The term public key infrastructure (PKI) is often loosely thrown around, but is not often thoroughly explained. PKI, in a nutshell, is the collection of digital certificates, registration authorities, and certificate authorities that verify the validity of each participant in an encrypted network. Effectively, a PKI itself is simply a concept that defines the mechanisms that ensure that the user who is communicating with another user or computer on a network is who he says he is. PKI implementations are widespread and are becoming a critical component of modern network implementations. Windows Server 2003 fully supports the deployment of multiple PKI configurations, as defined in the following sections.

PKI deployments can range from simple to complex, with some PKI implementations utilizing an array of smartcards and certificates to verify the identity of all users with a great degree of certainty. Understanding the capabilities of PKI and choosing the proper deployment for an organization are subsequently a must.

Private Key Versus Public Key Encryption

Encryption techniques can primarily be classified as either symmetrical or asymmetrical. Symmetrical encryption requires that each party in an encryption scheme hold a copy of a private key, which is used to encrypt and decrypt information sent between the two parties. The problem with private key encryption is that the private key must somehow be transmitted to the other party without it being intercepted and used to decrypt the information.

Public key, or asymmetrical, encryption uses a combination of two keys, which are mathematically related to each other. The first key, the private key, is kept closely guarded and is used to encrypt the information. The second key, the public key, can be used to decrypt the information. The integrity of the public key is ensured through certificates, which will be explained in depth in following sections of this chapter. The asymmetric approach to encryption ensures that the private key does not fall into the wrong hands and only the intended recipient will be able to decrypt the data.

Certificates

A certificate is essentially a digital document that is issued by a trusted central authority and is used by the authority to validate a user's identity. Central, trusted authorities such as VeriSign are widely used on the Internet to ensure that software from Microsoft, for example, is really from Microsoft, and not a virus in disguise.

Certificates are used for multiple functions, such as the following:

  • Secure email

  • Web-based authentication

  • IP Security (IPSec)

  • Code signing

  • Certification hierarchies

Certificates are signed using information from the subject's public key, along with identifier information such as name, email address, and so on, and a digital signature of the certificate issuer, known as the Certificate Authority (CA).

Certificate Services in Windows Server 2003

Windows Server 2003 includes a built-in Certificate Authority (CA) known as Certificate Services. Certificate Services can be used to create certificates and subsequently manage them; it is responsible for ensuring their validity. Certificate Services is often used in Windows Server 2003 if there is no particular need to have a third-party verify an organization's certificates. It is common practice to set up a standalone CA for network encryption that requires certificates only for internal parties. Third-party certificate authorities such as VeriSign are also extensively used but require an investment in individual certificates.

Certificate Services for Windows Server 2003 can be installed as one of the following CA types:

  • Enterprise Root Certification Authority The enterprise root CA is the most trusted CA in an organization and should be installed before any other CA. All other CAs are subordinate to an enterprise root CA.

  • Enterprise Subordinate Certification Authority An enterprise subordinate CA must get a CA certificate from an enterprise root CA but can then issue certificates to all users and computers in the enterprise. These types of CAs are often used for load balancing of an enterprise root CA.

  • Standalone Root Certification Authority A standalone root CA is the root of a hierarchy that is not related to the enterprise domain information. Multiple standalone CAs can be established for particular purposes.

  • Standalone Subordinate Certification Authority A standalone subordinate CA receives its certificate from a standalone root CA and can then be used to distribute certificates to users and computers associated with that standalone CA.

To install Certificate Services on Windows Server 2003, follow these steps:

1.
Choose Start, Control Panel, Add or Remove Programs.

2.
Click Add/Remove Windows Components.

3.
Check the Certificate Services box.

4.
A warning dialog box will be displayed, as illustrated in Figure 13.4, indicating that the computer name or domain name cannot be changed after you install Certificate Services. Click Yes to proceed with the installation.

Figure 13.4. Certificate Services warning.

5.
Click Next to continue.

6.
The following screen, shown in Figure 13.5, allows you to create the type of CA required. Refer to the preceding list for more information about the different types of CAs that you can install. In this example, choose Enterprise Root CA and click Next to continue.

Figure 13.5. Selecting the type of CA server to install.

7.
Enter a common name for the CAfor example, CompanyABC Enterprise Root CA.

8.
Enter the validity period for the Certificate Authority and click Next to continue. The cryptographic key will then be created.

9.
Enter a location for the certificate database and then database logs. The location you choose should be secure, to prevent unauthorized tampering with the CA. Click Next to continue. Setup will then install the CA components.

10.
If IIS is not installed, a prompt will be displayed, as shown in Figure 13.6, indicating that Web Enrollment will be disabled until you install IIS. If this box is displayed, click OK to continue.

Figure 13.6. IIS warning in the CA installation procedure.

11.
Click Finish after installation to complete the process.

Using Smartcards in a PKI Infrastructure

A robust solution for a public key infrastructure network can be found in the introduction of smartcard authentication for users. Smartcards are plastic cards that have a microchip embedded in them; this chip allows them to store unique information in each card. User login information, as well as certificates installed from a CA server, can be placed on a smartcard. When a user needs to log in to a system, she places the smartcard in a smartcard reader or simply swipes it across the reader itself. The certificate is read, and the user is prompted only for a PIN, which is uniquely assigned to each user. After the PIN and the certificate are verified, the user can log in to the domain.

Smartcards have obvious advantages over standard forms of authentication. It is no longer possible to simply steal or guess someone's username and password in this scenario as the username can be entered only via the unique smartcard. If stolen or lost, the smartcard can be immediately deactivated and the certificate revoked. Even if a functioning smartcard were to fall into the wrong hands, the PIN would still need to be used to properly access the system. Smartcards are fast becoming a more accepted way to integrate the security of certificates and PKI into organizations.

Encrypting File System

Just as transport information can be encrypted via certificates and public key infrastructure, so too can the NT File System (NTFS) on Windows Server 2003 be encrypted to prevent unauthorized access. The Encrypting File System (EFS) option in Windows Server 2003 allows for this type of functionality and improves on the Windows 2000 EFS model by allowing offline folders to maintain encryption sets on the server. EFS is advantageous, particularly for laptop users who tote around sensitive information. If the laptop or hard drive is stolen, the file information is worthless because it is scrambled and can be unscrambled only with the proper key. EFS is proving to be an important part in PKI implementations.

Integrating PKI with Non-Microsoft Kerberos Realms

Windows Server 2003's Active Directory component can use the PKI infrastructure, which utilizes trusts between foreign non-Microsoft Kerberos realms and Active Directory. The PKI infrastructure serves as the authentication mechanism for security requests across the cross-realm trusts that can be created in Active Directory.


Using IPSec Encryption with Windows Server 2003

IP Security (IPSec), mentioned briefly in previous sections, is essentially a mechanism for establishing end-to-end encryption of all data packets sent between computers. IPSec operates at Layer 3 of the OSI model and subsequently uses encrypted packets for all traffic between members.

IPSec is often considered to be one of the best ways to secure the traffic generated in an environment, and is useful for securing servers and workstations both in high-risk Internet access scenarios and also in private network configurations for an enhanced layer of security.

The IPSec Principle

The basic principle of IPSec is this: All traffic between clientswhether initiated by applications, the operating system, services, and so onis entirely encrypted by IPSec, which then puts its own header on each packet and sends the packets to the destination server to be decrypted. Because every piece of data is encrypted, this prevents electronic eavesdropping, or listening in on a network in an attempt to gain unauthorized access to data.

Several functional IPSec deployments are available, and some of the more promising ones are actually built into the network interface cards (NICs) of each computer, performing encryption and decryption without the operating system knowing what is going on. Aside from these alternatives, Windows Server 2003 includes a robust IPSec implementation by default, which can be configured to use a PKI certificate network or the built-in Kerberos authentication provided by Active Directory on Windows Server 2003.

Key IPSec Functionality

IPSec in Windows Server 2003 provides for the following key functionality that, when combined, provides for one of the most secure solutions available for client/server encryption:

  • Data Privacy All information sent from one IPSec machine to another is thoroughly encrypted by such algorithms as 3DES, which effectively prevent the unauthorized viewing of sensitive data.

  • Data Integrity The integrity of IPSec packets is enforced through ESP headers, which verify that the information contained within an IPSec packet has not been tampered with.

  • Anti-Replay Capability IPSec prevents streams of captured packets from being resent, known as a "replay" attack, blocking such methods of obtaining unauthorized access to a system by mimicking a valid user's response to server requests.

  • Per-Packet Authenticity IPSec utilizes certificates or Kerberos authentication to ensure that the sender of an IPSec packet is actually an authorized user.

  • NAT Transversal Windows Server 2003's implementation of IPSec now allows for IPSec to be routed through current NAT implementations, a concept that will be defined more thoroughly in the following sections.

  • Diffie-Hellman 2048-Bit Key Support Virtually unbreakable Diffie-Hellman 2048-bit key lengths are supported in Windows Server 2003's IPSec implementation, essentially assuring that the IPSec key cannot be broken.

IPSec NAT Transversal

As previously mentioned, IPSec in Windows Server 2003 now supports the concept of Network Address Translation Transversal (NAT-T). Understanding how NAT-T works first requires a full understanding of the need for NAT itself.

Network Address Translation (NAT) was developed simply because not enough IP addresses were available for all the clients on the Internet. Because of this, private IP ranges were established (10.x.x.x, 192.168.x.x, and so on) to allow all clients in an organization to have a unique IP address in their own private space. These IP addresses were designed to not route through the public IP address space, and a mechanism was needed to translate them into a valid, unique public IP address.

NAT was developed to fill this role. It normally resides on firewall servers or routers to provide for NAT capabilities between private and public networks. RRAS for Windows Server 2003 provides NAT capabilities as well.

Because the construction of the IPSec packet does not allow for NAT addresses, IPSec traffic has, in the past, simply been dropped at NAT servers, as there is no way to physically route the information to the proper destination. This posed major barriers to the widespread implementation of IPSec because many of the clients on the Internet today are addressed via NAT.

NAT Transversal, which is a new feature in Windows Server 2003's IPSec implementation, was jointly developed as an Internet standard by Microsoft and Cisco Systems. NAT-T works by sensing that a NAT network will need to be transversed and subsequently encapsulating the entire IPSec packet into a UDP packet with a normal UDP header. NAT handles UDP packets flawlessly, and they are subsequently routed to the proper address on the other side of the NAT.

NAT Transversal works well but requires that both ends of the IPSec transaction understand the protocol so as to properly pull the IPSec packet out of the UDP encapsulation. With the latest IPSec client and server, NAT-T becomes a reality and is positioned to make IPSec into a much bigger success than it is today.

Note

NAT-T was developed to keep current NAT technologies in place without changes. However, some implementations of NAT have attempted to make IPSec work natively across the translation without NAT-T. Disabling this functionality with NAT-T may be wise, however, because it may interfere with IPSec since both NAT-T and the NAT firewall will be attempting to overcome the NAT barrier.


Configuring Simple IPSec Between Servers in a Windows Server 2003 Domain

IPSec is built into Windows Server 2003 machines and is also available for clients. In fact, basic IPSec functionality can easily be set up in an environment that is running Windows Server 2003's Active Directory because IPSec can utilize the Kerberos authentication functionality in lieu of certificates. Subsequently, it is a fairly straightforward process to install and configure IPSec between servers and workstations, and should be considered as a way to further implement additional security in an environment.

The procedure outlined in the following sections illustrates the setup of a simple IPSec policy between a Web server and a client on a network. In this example, the Web server is SERVER7 and the client is CLIENT2.

Viewing the IPSec Security Monitor

To view the current status of any IPSec policies, including the ones that will be created in this procedure, the IPSec Security Monitor MMC snap-in on SERVER7 must be opened. The MMC snap-in can be installed and configured by following these steps:

1.
Choose Start, Run and type mmc into the Run dialog box. Click OK when complete.

2.
In MMC, choose File, Add/Remove Snap-in.

3.
Click the Add button to install the snap-in.

4.
Scroll down and select IP Security Monitor; then click the Add button followed by the Close button.

5.
The IP Security Monitor MMC snap-in should now be visible, as illustrated in Figure 13.7. Click OK.

Figure 13.7. Adding the IP Security Monitor MMC snap-in.

6.
In MMC, expand to Console Root\IP Security Monitor\SERVER7.

7.
Right-click on SERVER7 and choose Properties.

8.
Change the auto refresh setting from 45 seconds to 5 seconds or less. Click OK when finished. You can then use the MMC IP Security Monitor console to view IPSec data.

Establishing an IPSec Policy on the Server

Default IPSec policies are enabled on Windows Server 2003 and newer clients. To access these settings, follow this procedure on SERVER7:

1. | Choose Start, All Programs, Administrative Tools, Local Security Policy.
2. | Navigate to Security Settings\IP Security Policies on Local Computer.
3. | In the details pane, right-click Server (Request Security) and select Assign.

The following three default IPSec policies available allow for different degrees of IPSec enforcement:

  • Server (Request Security) In this option, the server requests but does not require IPSec communications. Choosing this option allows the server to communicate with other non-IPSec clients. It is recommended for organizations with lesser security needs or those in the midst of, but not finished with, an implementation of IPSec because it can serve as a stop-gap solution until all workstations are IPSec configured. This option does allow for some of the enhanced security of IPSec but without the commitment to all communications in IPSec.

  • Client (Respond Only) The Client option allows the configured machine to respond to requests for IPSec communications.

  • Secure Server (Require Security) The most secure option is the Require Security option, which stipulates that all network traffic be encrypted with IPSec. This policy effectively locks out other types of services that are not running IPSec, and should be set only if a full IPSec plan has been put into place.

Establishing an IPSec Policy on the Client

CLIENT2 will likewise need to be configured with a default IPSec policy, in a similar fashion to the server policy defined in the preceding section. To configure the client on Windows XP, follow these steps:

1.
Choose Start, All Programs, Administrative Tools, Local Security Policy. (Administrative Tools must be enabled in the Task Manager view settings.)

2.
Navigate to Security Settings\IP Security Policies on Local Computer.

3.
Right-click Client (Respond Only) and select Assign, as illustrated in Figure 13.8.

Figure 13.8. Creating a Client IPSec policy.

[View full size image]

Verifying IPSec Functionality in Event Viewer

After the local IPSec policies are enabled on both CLIENT2 and SERVER7, IPSec communications can take place. To test this, either ping the server from the client desktop, or perform other network tests, such as accessing SERVER7's Web page or file shares.

A quick look at the IP Security Monitor that was established in MMC on SERVER7 shows that IPSec traffic has been initialized and is logging itself, as you can see in Figure 13.9.

Figure 13.9. Viewing IP Security Monitor logging.

[View full size image]

In addition to using the IP Security Monitor to log IPSec traffic, the Security log in the Event Viewer on SERVER7 can be used to check for IPSec events. Filter specifically for Event ID 541, which indicates successful IPSec communications, as shown in Figure 13.10.

Figure 13.10. Viewing an IPSec Event log success entry.

These default IPSec policies are useful in establishing ad hoc IPSec between clients on a network, but are limited in their scope. Proper planning of an enterprise IPSec implementation is necessary to effectively secure an entire environment using custom IPSec policies.


Summary

In today's interconnected networks, transport-level security is a major, if not one of the most important, security consideration for any organization. Securing the communications between users and computers on a network is vital, and in some cases required by law. Windows Server 2003 builds on the strong security base of Windows 2000 to include support for transport-level security mechanisms such as VPNs, IPSec, and PKI certificatebased infrastructures. Proper configuration and utilization of these tools can effectively lock down an organization's transmission of data and ensure that it is used only by the proper individuals.


Best Practices

  • To secure a networking environment, deploy some or many of the transport-level security technologies available.

  • Because even the most secure infrastructures are subject to vulnerabilities, it is recommended to deploy multiple layers of security on critical network data.

  • L2TP is the preferred protocol for use with VPNs in Windows Server 2003 because it provides for the encapsulation of data over multiple network protocols.

  • Implement IPSec to secure the traffic generated in an environment and for securing servers and workstations both in high-risk Internet access scenarios and also in private network configurations.


Chapter 14. Windows Server 2003 Passports

In This Chapter

  • The Benefits of Using .NET Passports

  • Installing and Configuring .NET Passports

  • Working with .NET Passport Accounts

  • Using Passports with Web-Based Applications

  • Using .NET Passports and Mobile Devices

  • Additional Layers of Security

  • .NET Passport Policies

  • Other Passport Services

  • Passport Licensing

Just visiting some Web sites, you will find it hard not to notice the option to use .NET Passports. .NET Passports allow organizations to service individuals, groups, and even entire companies online to provide event-driven information or store other personalized information. After a user creates a .NET Passport account, she needs to remember only her .NET Passport name (for example, her email address) and password to access multiple Web sites including commerce sites that use .NET Passport services. This feature provides single sign-in (SSI) functionality for users to access multiple Web sites, but it can also be extended to an organization's intranet, Web-based mail system, and more.

.NET Passports are protected by encryption and strict privacy policies. A user can permit some or all of this information he provides to be sent to a particular Web site. For instance, a user signs onto a Web site using his .NET Passport. The user can then opt to provide additional information because this particular Web site is an e-commerce site that he trusts.

The .NET Passport SSI option enables organizations to provide consumers with an easy and secure way to sign in and make transactions on a Web site. Microsoft also has developed .NET Passport for Kids, which helps a Web site comply with the Children's Online Privacy Protection Act (COPPA) standards. COPPA requires that operators of online services or Web sites obtain parental consent prior to the collection, use, disclosure, or display of children's personal information.


The Benefits of Using .NET Passports

Using passports on your own site or for a personal account provides numerous benefits. .NET Passport is designed for both consumers and businesses alike, and some of its many benefits are as follows:

  • .NET Passport provides convenient and quicker authentication service.

  • SSI keeps users from having to remember different usernames and passwords for different sites they visit.

  • .NET Passport allows users to easily connect to sites from various devices including, but not limited to, cell phones and Pocket PCs.

  • .NET Passport allows businesses to easily recognize customers and personalize their experience.

  • .NET Passport is versatile, allowing you to apply it to various access methods, including Active Directory and Web-based applications such as Outlook Web Access (OWA).

  • Organizations requiring tighter security can use a secondary layer of security (such as a four-digit personal identification number, or PIN, to accompany a password). The PIN cannot be stored on the local computer or the organization hosting .NET Passport services.


Installing and Configuring .NET Passports

The .NET Passport service is one of many .NET services that Microsoft provides. As with any service that you want to add to your existing infrastructure, you will want to thoroughly test .NET Passports in a lab environment prior to implementing the service in a live production environment.

Because .NET Passports contain information about users, the information must be protected to ensure privacy and confidentiality. As a result, before you use the .NET Passport service, you must meet various Microsoft prerequisites to keep .NET Passport legitimate throughout the Internet. The following process is required before you implement .NET Passports on your site:

  • Create a passport account on Microsoft's .NET Passport Web site (http://www.passport.com).

  • Review and adhere to the .NET Passport Privacy Policy located at http://www.passport.net/Consumer/PrivacyPolicy.asp and the Microsoft Statement of Policy at http://www.microsoft.com/info/privacy.htm. If you are planning to use .NET Passport for Kids, it is important to also review and adhere to the .NET Passport Kids Privacy Statement (http://www.passport.net/Consumer/KidsPrivacyPolicy.asp?lc=1033).

  • Obtain a Preproduction (PREP) ID to begin testing .NET Passport on your site. As mentioned earlier, you should always test this functionality before putting it into production.

  • When you're developing a Web site with .NET Passport in the PREP environment (and in a live production environment), you must display your privacy policy. This policy should conform to Microsoft's policies.

  • Prior to your site going live with .NET Passport, you must sign a contract.

After a site is issued a Site ID, an encryption key is sent to the site. The key is a shared secret between the site and the .NET Passport system (that is, the login server). This allows users to be authenticated and, equally important, it allows the site to obtain user authentication information.

Caution

Although rare, in some cases, upgrading from Microsoft .NET Passport Software Development Kit (SDK) version 2.1 to the Windows Server 2003 version of .NET Passport could potentially downgrade .NET Passport functionality. To minimize any possible effects from an upgrade, run IIS in 6.0 mode rather than IIS 5.0 compatibility mode. Whenever possible, perform a clean install of the Windows Server 2003 version of .NET Passport.

Obtaining a PREP ID

A PREP ID allows an organization to use .NET Passport on a test site before going live. Without the PREP ID, sites could not test the .NET Passport authentication. This PREP ID is for testing use only, so a live Site ID is required to be able to use the .NET Passport site in production.

To obtain a PREP ID, go to the Microsoft .NET Services Manager Web site located at https://www.netservicesmanager.com, as shown in Figure 14.1.

Figure 14.1. The .NET Services Manager Web site.

[View full size image]

At this point, you're given the option to

  • Create a .NET Passport application for the development/test environment

  • Download information on how to implement various .NET Services

  • View sample sites

  • Obtain business-related information

  • Create and manage an application

To begin the registration process for obtaining a .NET Passport PREP ID, do the following:

1.
Click the Create and Manage an Application link. If you haven't signed in with a .NET Passport account, you'll be directed to either log on or create a new .NET Passport account. Refer to "Working with .NET Passport Accounts" later in this chapter for information on creating a .NET Passport account.

2.
After reading the terms and agreement, click the Accept Terms button to continue. This brings you to the User Information page, which asks for your contact information. You'll also choose which notifications you want to receive.

3.
On the Create and Manage an Application page, click Create Application.

4.
On the Create Preproduction Application page, type in the name of the application and then click the Submit button.

5.
Click the Add Service button and select the type of passport service(s) for your development/test site. You can choose from .NET Passport, Kids Passport with SSI, or Microsoft Alerts. Click the Next button when done to advance to the registration pages.

6.
Depending on which selection you made, you have to fill out different registration information. In this example, the Web site features the .NET Passport option. On the General .NET Passport Information page, enter the appropriate information in the dialog boxes. The boldface areas such as Web Site Title, Domain Name, Default Return URL, and Privacy Policy Location are required information. When you're finished, click the Next button so you can begin providing co-branding information.

7.
Enter the appropriate co-branding information. The minimum required information is the co-branding image. Click Next to provide other .NET Passport-related information, such as registration return pages, and disable copyright, as shown in Figure 14.2.

Figure 14.2. .NET Passport registration.

[View full size image]

8.
On the next Web page, enter the .NET Passport SSI information. The Expire Cookie URL information is required. This is the location of the page that will delete all the cookies set by .NET Passport for the site.

9.
If you selected Kids Passport, as in this example, enter the account removal and data URLs as well as the type of consent needed (limited or full consent).

10.
Click the Submit button when done. The next screen provides the .NET Passport information for your site. The page displays the Site ID (for the preproduction environment), last modification date, status, and compliance rating.

Using the Passport Manager Administration Utility

Administrators must use the Passport Manager Administration utility, shown in Figure 14.3, to install and configure .NET Passports. This utility should be run after receiving the PREP ID.

Figure 14.3. The Passport Manager Administration utility.

[View full size image]

In previous versions of .NET Passport, the Passport Manager Administration utility was provided in the SDK, which also includes several tools and documentation to make implementing .NET Passports much easier. In Windows Server 2003, the Passport Manager Administration utility is bundled within the operating system.

To begin using the Passport Manager Administration utility, do the following:

1. | Choose Start, Run, and then type MSPPCNFG.EXE in the Run dialog box to start the Passport Manager Administration utility.
2. | Enter the PREP ID that you received into the Site ID box.
3. | Enter the appropriate information about your site such as Return URL, Cookie Path, and so on.

For organizations with multiple servers, you can save the Passport Manager Administration utility configuration to a file that can be exported to another server. Select Save As from the File menu to save a Passport Configuration File (*.ppi).

Obtaining an Encryption Key

For your site to acquire user authentication information from the .NET Passport system for use on the participating site, you must first download an encryption key. The encryption key gives a site authorization to receive user authentication information from the .NET Passport system.

To download an encryption key, do the following:

1.
Go to the Microsoft .NET Services Manager Web site and sign in using .NET Passport.

2.
Click the Applications tab and then click Manage Applications.

3.
Select the application that you created earlier and then click the Next button.

4.
Click the Download Key option, and then click the Request Key button. Microsoft then sends you an email containing the link to use to obtain the key.

5.
On the Create Your Security Key page, shown in Figure 14.4, type in a four-digit or character security key twice and provide answers to the three questions of your choosing. It is important to remember your answers for the second part of obtaining your key. Click Continue when done.

Figure 14.4. Obtaining an encryption key.

[View full size image]

6.
Answer the three questions that you just provided answers for and then click Continue.

7.
On the Security Key Sign-in page, enter the four-digit or character security key and click the Sign In button.

8.
Scroll down the Download Key page and then select the operating system and Web server you plan to use.

9.
Click the Download Key button. When prompted for the file download, click Save.

Microsoft provides the step-by-step directions for installing the encryption key on the Download Key page. However, for convenience, the directions are described here. The following directions assume that you have already set the correct PREP or Site ID and have downloaded the encryption key to the Web server:

1. | Choose Start, Programs, Administrative Tools and open the Services snap-in. Then choose to stop the IISAdmin service. This will stop all other IIS-related services.
2. | Choose Start, Run, and open the command prompt by typing cmd.exe. Then go to the location where you downloaded the encryption key.
3. | Type partner####_#.exe /addkey, where # is the PREP or Site ID.
4. | Type partner####_#.exe /makecurrent /t 0.
5. | Restart the IISAdmin service and other IIS-related services that were stopped (for example, the World Wide Web Publishing service).

Building .NET Passport for Production

After thoroughly testing .NET Passport in a lab environment, you need to submit a request to obtain a .NET Services agreement. This agreement should be signed before you introduce the .NET Passport service in a production environment. You can make the request by sending email to netservs@microsoft.com. It is better to request this agreement well in advance to prevent any possible interruption in service.

The .NET Passport application that you created on Microsoft's .NET Services Manager Web site must also be submitted with compliance criteria before obtaining the production Site ID and encryption key. Note that you cannot use the PREP ID and encryption key from the development/testing environment.

To submit compliance criteria, perform the following steps:

1. | Go to the Microsoft .NET Services Manager Web site and sign in using .NET Passport.
2. | Click the Applications tab and then click Manage Applications.
3. | Select the application you created earlier and then click the Next button.
4. | Click Submit Compliance to roll your application into production.
5. | Review the information on the Web page and then click Go to Manage Agreements.
6. | At this stage, you can either request a Microsoft Services Agreement or request an Agreement Association. The first option is for those organizations that do not already have a signed Microsoft Services Agreement. After you have a signed agreement, however, you can choose the Request Agreement Association option to then be able to submit your application for compliance review.


Working with .NET Passport Accounts

.NET Passport accounts allow users to minimize the number of account IDs and passwords that they must remember. .NET Passport for Kids is a feature of .NET Passport SSI that allows parents to control how children's profile information is collected, used, and shared on the Internet.

If an organization's Web site already has an authentication mechanism, you must consider whether to convert any existing accounts or have .NET Passport co-exist with the current authentication. Lack of proper planning and design for this issue can significantly impact existing users or customers.

Converting Accounts

When a site wants to use .NET Passport as its primary authorization mechanism, it must convert its accounts to this service. All users log in to the site as they normally would and then are required to register for a .NET Passport and associate their current information with .NET Passport. Anytime thereafter, the users would use only their .NET Passport accounts.

Using Site Accounts and .NET Passport

Some sites may elect to keep current account information active, whereas new users or customers are required to use a .NET Passport account. Another alternative is to give users the option to either use .NET Passport or create a standard account.

Note

If sites use multiple authentication mechanisms and therefore two separate directories of information, the amount of administration and maintenance involved can increase substantially.

Alternatively, sites can introduce .NET Passport to users gradually. This approach allows coexistence but allows the sites to move forward with .NET Passport.

Creating Passport Accounts

Users can create a .NET Passport account using one of four methods:

  • By registering at the .NET Passport registration page (http://www.passport.com), as shown in Figure 14.5

  • By registering at a participating site, which automatically redirects users to a Microsoft-hosted (and possibly co-branded) .NET Passport registration page

  • By registering for an email account on MSN Hotmail (http://www.hotmail.com) or through the MSN Internet Access ISP service, which automatically registers users for the .NET Passport SSI service

  • By registering using the Microsoft Windows XP .NET Passport Registration Wizard

Figure 14.5. The .NET Passport registration page.

[View full size image]

Note

Signing up for a .NET Passport does not require a valid email address. Users can enter any email address in the form of someone@domain.com. Also, the password has a minimum required length of six characters.

There are only two required fields to create a .NET Passport: an email address and a password. However, participating sites may optionally choose to require additional fields, such as the following:

  • Accessibility Needs

  • Country/Region

  • Date of Birth

  • First and Last Name

  • Gender

  • Postal Code

  • State

  • Time Zone

  • Occupation


Using Passports with Web-Based Applications

.NET Passport is not just about providing authentication to Web sites. Because it's an integral part of Windows .NET and the Windows Server 2003 operating system, one of the purposes of .NET Passport is to integrate with other computers, devices, and services to deliver a much richer solution for users. This integration allows .NET Passport to seamlessly work with other Web-based services and applications.

An example of .NET Passport integrating with Web-based services and applications is using .NET Passport with Outlook Web Access (OWA). OWA is a feature of Microsoft Exchange that operates as an HTTP virtual server to provide feature-rich Outlook mail client functionality through the Web. Because OWA relies on IIS, simply changing the authentication mechanism to .NET Passport allows .NET Passport to be used instead of Basic Authentication.


Using .NET Passports and Mobile Devices

.NET Passport supports Windows Pocket PC 2002 Phone Edition or higher and cell phones using Microsoft Mobile Explorer (MME) in HTML, i-mode, Wireless Access Protocol (WAP), or Handheld Device Markup Language (HDML). Some features are not supported due to screen size, screen resolution, and input mechanisms. Mobile devices do have access to

  • Registration

  • SSI

  • .NET Passport for Kids (except the consent process)

  • Sign out


Additional Layers of Security

Some sites may want or require extra security measures to be put into place to further protect account information. .NET Passport can be used with Secure Sockets Layer (SSL), which encrypts Web-related traffic between the client and the site. This protects against a hacker capturing and deciphering traffic between the user and the site.

Another security mechanism that can be utilized is to require users to enter a separate credential before signing in with their email addresses and passwords. This additional security mechanism is a security key and is similar to a personal identification number (PIN) that you use at an ATM.

When a user attempts to sign into a participating site that requires a security key, he will be directed to the .NET Passport registration page. The user will need to enter a four-character security key and then select and answer a minimum of three questions. These questions, called secret questions, will help to validate the user in case the user forgets the secret key. The secret key cannot be set to log on automatically, nor can it be stored on the user's computer.

.NET Passport Authentication

.NET Passport authentication begins when a user requests or is directed to the .NET Passport sign-in page. The user's email address and password are verified against an entry in the .NET Passport database. After the user is authenticated, the .NET Passport PUID and .NET Passport profile information for that user are loaded.

The .NET Passport PUID and profile are used to create the following .NET Passport cookies:

  • Ticket cookie Contains the PUID and time stamp

  • Profile cookie Contains .NET Passport profile information

  • Participating site cookie Contains the list of sites that a user has signed into

As described earlier, in "Installing and Configuring .NET Passports," a site must register itself, adhere to Microsoft's privacy policies, and more before being able to obtain a .NET Passport user's authentication information. It is important to note that a user's email address and password are not shared with a participating site. A site receives user authentication information from the .NET Passport system using the encryption key provided by Microsoft. The encryption key is also used to encrypt the ticket and profile cookies and then returns the information to the return URL provided in the authentication request. Internet Explorer (IE) on the client machine then creates the three .NET Passport cookies.

At this point, the browser redirects the user to the participating site and the Ticket and Profile cookies are sent to the participating site. The participating site's Passport Manager Administration utility manages cookie information, and the participating site can store or upgrade user information.

.NET Passport Cookies

Any time a user signs out or the browser is closed, the .NET Passport system runs a script to delete all three temporary cookies from the participating site. This prevents others from using the cookies and potentially compromising security. If the user does not sign out or close the browser, the .NET Passport cookies will expire after a specified period of time controlled by the .NET Passport system or the participating site.

Although the .NET Passport system authenticates users, participating sites can use the encrypted .NET Passport Ticket and Profile data to generate the site's own cookies in its own domain for that user. These newly created cookies are placed on the user's machine and can be used only on the specific participating site. Participating sites can use this feature to personalize the user's experience while visiting their sites. For example, a user's profile and preferences can be stored on her machine so that the next time she connects to the participating site, the Web site's content is personalized for that particular user.

Securing Communications

As mentioned earlier, a secure channel can be established when a user connects to the .NET Passport sign-in page. When the connection is established using SSL, a user can sign in securely.

.NET Passport supports either Windows Server 2003 version of SSL or a third-party SSL certificate provider. The version of SSL bundled within Windows Server 2003 is a more efficient and faster implementation than previous versions of SSL. However, SSL is a processor-intensive process that can impede performance for higher-capacity Web sites. For this reason, you should consider using high-performance network interface cards (NICs) that also have the capability to offload SSL processing from the system processor(s). Doing so can significantly boost Web site response and performance.

Most users may not even be aware of the fact that SSL is being used to provide a secure communications channel by encrypting traffic between the users' machines and the participating Web sites. SSL implementation is transparent, and it does not affect how users sign into the site.


.NET Passport Policies

.NET Passport services have been scrutinized, especially in terms of privacy, confidentiality, and security. Many safeguards have been put into place to ensure that none of these aspects are compromised. The safeguards examined so far are primarily technical in nature, but Microsoft has also committed to ensuring adequate safety measures and policies are in place as well.

Microsoft has many policies that must be adhered to before .NET Passport can be implemented. These policies include

  • .NET Passport Privacy Statement To read this policy on how Microsoft protects personal information while using the .NET Passport Web site and the .NET Passport Service at participating sites, go to http://www.passport.net/Consumer/_PrivacyPolicy.asp.

  • Microsoft.com Statement of Policy This set of policies is documented at http://_www.microsoft.com/info/privacy.htm. It states Microsoft's blanket privacy policy in terms of how personal information is collected, used, controlled, stored, accessed, and secured.

  • .NET Passport Kids Privacy Statement Located at http://www.passport.net/_Consumer/KidsPrivacyPolicy.asp?lc=1033, this privacy statement describes the policies of .NET Passport and how it relates to .NET Passport for Kids. It then details the parental consent process and how it can be used to protect children.

Fair Information Practices

Microsoft has based .NET Passport policies on the Fair Information Practices (FIP) recognized by a number of industry and government organizations, including the Online Privacy Alliance, the U.S. Federal Trade Commission, the European Union Directorate General, and the majority of domestic and foreign privacy advocacy groups.

These policies are structured based on notice, consent, access, security, and remedy and enforcement. In other words, Microsoft's corporate policy, not just .NET Passport policies, is intended to provide the utmost security, privacy, and user control over personal information.


Other Passport Services

Throughout this chapter, the three .NET Passport services have been mentioned but the concentration has been on .NET Passport SSI. In the following sections, the other two services will be examined.

.NET Passport for Kids

.NET Passport for Kids is an extension of the .NET Passport SSI service, and it complies with COPPA standards and requirements for protecting children. It requires participating sites to obtain parental permission prior to collecting, using, disclosing, or displaying a child's information. This service protects children under the age of 13 from Web sites' typical routine personal information retrieval.

Parents can also control consent levels for .NET Passportparticipating sites using the .NET Passport for Kids service. Table 14.1 describes the levels of consent available to parents.

Table 14.1. .NET Passport for Kids Consent Levels

Consent Level

Consent Description

Deny

The site or service cannot collect personally identifiable information from the child. The trade-off for setting this option is that some sites may not allow children to use the site if this option is chosen.

Limited

The site or service can collect, store, and use the information it collects from the child. However, this information cannot be disclosed.

Full

The site or service can collect, store, and use the information it collects from the child, and it can also disclose the information to a third party (individual or company).

.NET Passport for Kids checks the profile (date of birth and country fields) to determine whether the child is protected by COPPA. If so, .NET Passport for Kids then checks the profile to determine the level of consent granted. Based on this information, the child is either allowed to use a participating site, or a notification is displayed informing the child that consent is required.


Passport Licensing

The .NET Passport service is provided at no cost to end users. However, organizations that want to add .NET Passport functionality and services to their own Web site must sign a three-year, nonexclusive service agreement. This service agreement ensures that an organization adheres to the specific guidelines regarding privacy and that the service's integrity is kept.

Although testing the .NET Passport implementation is not a requirement, it is highly recommended. If an organization wants to test using the .NET Passport service, the .NET service agreement does not have to be signed.

Note

To request a .NET Passport service agreement, send an email to netservs@microsoft.com or visit http://www.microsoft.com/licensing/. You will need to provide your organization's contact information.

Full details on licensing costs, guidelines to follow, and more for an organization's site are provided in an email that Microsoft sends after receiving the request.


Summary

.NET Passport services offer a convenient, easy, and secure way to consolidate usernames and passwords. Although the initial release of .NET Passports extended only from e-commerce sites to individuals, Windows Server 2003 provides the ability to establish client-to-network .NET Passport communications. .NET Passports provide centralized profile storage and a tracking mechanism that can be used for single sign-on authentication to multiple network services. No longer do users need to log on to their Web email server, then log on to their corporate intranet server, and then log on separately to their LAN or WAN network. .NET Passports simplify logon authentication and provide a way for organizations to synchronize user logon access to multiple network resources from a single logon account.


Best Practices

  • Use Windows Server 2003 Passports to keep users from having to remember different usernames and passwords for different sites that they visit, including your own.

  • Use .NET Passport to personalize the customer's experience.

  • Implement .NET Passport for Web-based applications such as Outlook Web Access (OWA).

  • If your organization requires tighter security, use a secondary layer of security (such as a four-digit PIN to accompany a password).

  • Review and adhere to the .NET Passport Privacy Policy located at http://www.passport.net/Consumer/PrivacyPolicy.asp and the Microsoft Statement of Policy at http://www.microsoft.com/info/privacy.htm.

  • If you are planning to use .NET Passport for Kids, be sure to review and adhere to the .NET Passport Kids Privacy Statement (http://www.passport.net/Consumer/_KidsPrivacyPolicy.asp?lc=1033).

  • Build Windows Server 2003 Passport functionality from scratch whenever possible instead of upgrading from earlier versions of .NET Passport. Convert existing accounts to Windows Server 2003 Passports.

  • Use SSL with .NET Passports to provide additional security.


Chapter 15. Security Policies and Tools

In This Chapter

  • Security Policies

  • Security Framework

  • Windows Server 2003 Security Policy Toolbox

We've examined security mechanisms throughout this book, but to be able to successfully protect an organization, security must start at the topmost level and filter down throughout the organization. Executive management must define at a high level what security policies should be put in place, the type of information to be protected, and the level of protection that is required. Employees, especially IT personnel, must be made aware of these organizational security policies and adhere to them or otherwise deal with the consequences for noncompliance.

Employing security policies and the tools used to enforce the policies is the first step in keeping the organization secure; these elements provide the framework for the amount of security that the business requires. Without them, some areas may be protected, whereas others are neglected. This can ultimately jeopardize the organization by leaving security holes in which external and internal users can take advantage and compromise security.

This chapter outlines what security policies are and how they are used by organizations to create a security framework using administrative, physical, and technical controls. In addition, this chapter covers general and Windows Server 2003 security-focused technologies that can be applied as controls for a security framework.


Security Policies

At its core, a security policy is what defines the security posture of an organization. This posture should include protecting an organization's information, information systems, and people in a manner that reduces or manages the risk to these assets. To perform this role, a security policy must define the rules for expected behavior and what the consequences are for violations of the policy, and it must provide a method to authorize security personnel to monitor, investigate, and respond to intruder alerts. In all cases, a security policy should provide a clear directive that provides a path for reaching an objective through procedures or actions that must be carried out.

Security policies vary from organization to organization, and they may depend on laws and regulations as well as liability issues for the industry or specific organization. For instance, healthcare-related companies have stricter security policies for keeping medical information private to conform to the Health Insurance Portability and Accountability Act (HIPAA), whereas financial institutions must ensure compliance with the Gramm-Leach-Bliley Act (GLBA).

Note

For more information on HIPAA and GLBA, go to http://cms.hhs.gov/hipaa/ and http://www.senate.gov/~banking/conf/, respectively.

Security policies incorporate standards, guidelines, procedures, and other mechanisms. These elements can be organized on how they apply to the organization. No matter what security policies are in place, they should be well documented, reviewed, taught, and practiced.

Policy Levels

An organization's security policies are not all the same. Many different types of policies apply to different levels within an organization. The level at which a policy applies in an organization is defined by a policy hierarchy. Because of differences between organizations, policy hierarchies might differ. Regardless, three policy levels are almost always included within all policy hierarchies: enterprise, issue-specific, and procedures and checklists.

Enterprise Policy Hierarchy

The intention of developing enterprise policies is to address security requirements for the entire organization rather than a specific system or group of systems. Many of these security policies relate to employees, their education, and the enforcement of security policies.

Issue-Specific Policy Hierarchy

Issue-specific policies address specific security needs within an organization. Examples of issue-specific policies are password policies, Internet usage policies, and antivirus policies.

Procedures and Checklists Policy Hierarchy

Procedures and checklists are not actually policies, but instead are designed to eliminate errors with policy compliance by providing a clear path for making decisions. To do this, procedures and checklists are created to define the how, where, and when of policies.

Roles and Responsibilities

When a security policy is created, the roles and responsibilities of individuals associated with the security policy must be defined. Defining roles and responsibilities dictates how individuals are to interact with a policy. For example, the creation and update of, enforcement of, or adherence to a policy are all responsibilities that must be assigned to individuals within an organization. If these roles are not defined, a policy effectively doesn't apply to anyone and becomes just another document.

Desktop Security Policy

Desktop security policies vary between organizations as well as within an organization. Predominately, specific desktop security policies are managed with GPOs to control or lock down the client machines. It's also important to have clearly defined security policies documented in the employee forms mentioned earlier in this chapter. Security policies relating to the desktop that may be enforced using a GPO or other means must support the formal, documented security policies for the organization. For more information on GPOs and how they can be applied to network clients, refer to Chapter 29, "Group Policy Management for Network Clients."

Another variance in how desktop security policies apply may depend on what the users' responsibilities and roles are within the organization. For example, you may require more control of the desktop for data entry workers than for knowledge workers.

Some possible desktop security policies to consider implementing include, but are not limited to, the following:

  • Limit the number of applications a user has access to use.

  • Restrict users from using company resources to play games, or even restrict them from installing any software.

  • Remove the username of the person who logged on last to the client machine. This keeps people from discovering other usernames and passwords.

  • Require users to change their passwords periodically. You may also want to consider tightening password history, length, and strength requirements. Also, users must not keep this information on sticky notes on their computers.

  • Mandate keeping documents on the file servers so that they are backed up every night. You can help alleviate concerns that documents aren't being backed up by using folder redirection.

Application Security Policy

The basic reason you should consider application security policies is that any invoked application or code can potentially identify or exploit security holes. A human resources (HR) application, for example, may unintentionally give access to confidential information after a specific key sequence is pressed.

As a best practice, consideration should be made for reviewing and documenting the following application-level security policies:

  • Establish Windows Server 2003's software restriction policies. This service provides a transparent, policy-driven means to regulate unknown or untrusted applications.

  • Support only those applications that are approved and are critical to the business.

  • Routinely update antivirus definition files to improve resilience against getting a virus.

  • Provide the least privilege principle to what data an application has access to.

  • Use Group Policy Objects (GPOs) to lock down the desktop so that users aren't given full access to the system. For example, disable the Run command or disallow use of the command prompt.

  • Thoroughly test Windows Server 2003 service packs and updates (especially the security-related updates) in a lab environment before deploying them in production.

  • Test and review application updates and patches to determine how they may affect application security and reliability.

An organization can benefit from many other possible application security policies. The type of security policy that you have will depend on business requirements. In any case, thoroughly reviewing and documenting these application security policies can benefit the network environment by tightening application security.

Network Security Policy

Network security policies are intended to provide specific and often detailed guidelines and rules to keep the network environment running optimally and securely. Specific policies should be set regarding network access, firewalls and required filtering, specific address or time restrictions, and much more.

Note

In addition to evaluating the best practices and recommendations regarding security in this book, it is also recommended to use the recommended best practices compiled by the National Institute of Standards and Technologies (NIST) and the National Security Agency (NSA). Both agencies provide security lockdown configuration standards and guidelines that can be downloaded from their Web sites (http://www.nist.gov and http://www.nsa.gov, respectively).

Both LAN and WAN environments should have security policies in regard to how and when the network is accessed. LAN and WAN environments are typically protected by firewalls or other security devices, but placing security policy restrictions on how and when users can access the network further tightens security.

If the network access security policy states that users are required to use virtual private network (VPN) connections or Terminal Services instead of dial-up to gain remote access, a possible intruder's options are further limited. Additional policies may also limit how VPN or Terminal Services connections can be made and what specific configurations are required (for example, every VPN must use L2TP and IPSec).

Network access auditing policies are also a recommended measure to monitor the environment. Reviewing audit logs on a predetermined schedule can identify possible attempts and security breaches.


Security Framework

A security framework is a set of controls that is used to limit exposure to vulnerabilities and threats. As a result, controls also enforce an organization's security policies and reduce the risk to which an organization is exposed. Although a wide range of potential controls can be implemented within a security framework, all controls are generally classified either as administrative, physical, or technical controls.

When choosing to implement a control, the following items should be considered:

  • Controls should be implemented as a response to risk.

  • Controls should be implemented at multiple levels throughout an organization. This is the practice of defense-in-depth (DID).

  • Controls should be monitored, reviewed, and audited to verify effectiveness.

  • A control can never completely eliminate risk. In relation, there is a fine line between an effective control and usability. A balance must be struck that addresses both risk and usability.

Administrative Controls

Administrative controls can be security policies or items such as standards, guidelines, procedures, checklists, and executive enforcement statements that set a clear directive for individuals to follow to ensure security. Because these controls interact directly with individuals, they tend to be scrutinized more rigorously than other controls. In addition, administrative controls are the foundations from which technical and physical controls are implemented and managed.

Although administrative controls contain many different important aspects, all organizations need to address four areas within their administrative controls. Organizations must educate their individuals about their security policies while enforcing those policies. Furthermore, there are form-based controls that must be applied to employees and IT staff.

Educating the Organization

To comply with security policies that are in effect, users need to know what those security policies are, the consequences of breaking those policies (for example, a warning letter and then termination), and most importantly, how breaking a security policy affects the organization, department, and individual.

Educating users on the organization's security policies can take many forms, including but not limited to the following:

  • New employee orientation

  • Security handbook

  • Training sessions

  • Banner notification (a basic form of awareness)

  • Bulletins in Exchange Server public folders

Two important points to consider when training users is that simply handing them information is not an effective means to educate users, and security policy education should be addressed continually. In other words, you should provide various forms of security policy education and do so on a periodic basis.

Policy Enforcement

Policy enforcement can be a tricky matter and, although enforcement may not be the most enjoyable aspect of security policies, it is a necessity. If you do not enforce the policies and the corresponding consequences, they are essentially ineffective.

This means that if consequences are defined, it is an information security department's job to provide information about compliance for a policy to ensure the enforcement of security standards. It is not, however, the job of the information security department to enact the consequences that are defined within a policy. The job of enforcement should fall squarely with the realm of the human resources department with support from upper management.

Therefore, enforcement must be tailored to the security policy rather than the individual. For instance, after setting a specific consequence such as termination for revealing to the public confidential information on a new product or service, following through with termination for a developer but not a management-level person can have grave consequences for the security policies and the organization.

Employee Forms

There are countless forms relating to an organization's security and corresponding policies. A few of these forms that should be signed prior to employment or as a mandatory procedure for existing employees are listed here:

  • Confidentiality agreement

  • Identification (such as badges, key cards, and usernames and passwords)

  • Software license agreement (such as policies on copying company software or installing unapproved software on the network)

After your organization creates employee security policy forms, it is recommended that you seek legal counsel to review these documents. Doing so helps to keep the documents in good standing.

IT Personnel Forms

In addition to the employee forms that apply to all employees, IT personnel should be required to sign additional forms to protect the network environment. These forms can include

  • Incident reporting policies and high-level procedures

  • Privacy agreements pertaining to the way systems are administered or operated

  • Additional integrity and ethics agreements in regard to system usage, disclosure of sensitive or confidential information, and more

Physical Controls

Physical controls relates to how the organization is physically protected from intrusion. Locking mechanisms (both externally and internally), video surveillance, facility-access control such as electronic or smartcard mechanisms, and perimeter boundaries (such as fences and gates) are all examples of how the organization can be protected. Simply documenting what is and is not in place is effectively an internal security audit. Audits often can strengthen security policies and practices.

Note

Internal security audits for all areas of the network help to define and strengthen security policies and practices. However, a third-party security expert or firm should periodically perform security audits on your infrastructure to ensure maximum security.

Technical Controls

Technical controls are technical items that are put in place to protect information systems and data. Examples of technical controls range from hardware-based firewalls and antivirus software, to any security feature that is inherit within a technical item. When implementing a technical control, it is important to understand that the threats posed to an organization are dynamic and changing. Therefore, technical controls should be implemented so they can quickly be adapted to changing threats and in an overlapping fashion at many levels within an organization. Furthermore, a technical control should be under constant review and audited to verify effectiveness and identify instances where the control has been circumvented.

Firewalls

Firewalls are often thought of as control points between an organization and the Internet. Although this is true, firewalls can also segment and protect internal areas within a company. There are many different types of firewalls, and their capabilities vary. The types of firewalls used in an organization should be consistent so that the configurations can be similar. In other words, it may be better to use a single firewall vendor throughout the organization rather than have multiple firewall types spread throughout all locations. This helps reduce complexity and ensures that the entire organization follows the same policy. On the other hand, security requirements may be stringent enough to warrant having two or more types of firewalls. For instance, two separate firewalls guarding the Internet border might be required to significantly reduce the likelihood of intrusion. Although the two firewalls increase the environment's complexity, two firewalls will be less likely to share the same vulnerabilities.

Equally important is that if your company uses more than one firewall, the configurations should be similar if not identical to other firewalls. Specific protocol or port rules should, where applicable, be applied in all locations. For example, a security policy stating that NetBIOS should be stopped at the firewall may keep a hacker from using NetBIOS ports to gain unauthorized access to the network. A security policy would help to prevent any other firewalls in the environment from opening ports 137, 138, and 139.

Note

Windows Server 2003 with SP1 contains a built-in firewall called Windows Firewall. Windows Firewall is a host-based stateful firewall designed to provide Windows servers and clients protection from network attacks that pass through perimeter controls or originate from within an organization. Windows Firewall is not designed to act as a perimeter firewall and should only be used as a supplemental control in conjunction with a full-featured firewall solution such as Microsoft Internet Security and Acceleration Server 2004 or Cisco PIX.

Intrusion Detection System

An intrusion detection system (IDS) is used to detect and notify administrators about malicious activity within an organization's network and information systems. If an IDS system is a reactive system, it not only notifies administrators but takes evasive action to protect the system or network it is monitoring. The typical use of IDS, however, is passive in nature and the use of reactive systems should be limited to special cases that require immediate action when an attack is encountered.

To detect malicious activities, an IDS may either use signature-based or anomaly-based detection methods. The signature-based detection method watches for patterns of activity identified as malicious based on a database of known past attacks. In some cases depending on the rule set, however, an IDS might be able to identity new attacks based on shared characteristics with past attacks. The second detection method, called anomaly-based detection, identifies malicious activity based on baselines that have been defined by administrators or learned from sampling past activity (network- or application-based). If an anomaly-based IDS perceives activity to be different from normal activity, it treats the activity as malicious.

There are two types of IDSs. The most known type is called a network intrusion detection system (NIDS). A NIDS is used to capture network traffic information from various sensors usually positioned at network choke points. The captured network data is then analyzed for traces of malicious activity. The second type of IDS is called a host-based intrusion detection system (HIDS). A HIDS resides on a host system and identifies malicious behavior by monitoring such things as application logs, file system changes, application calls, and other system activities.

Policies surrounding IDSs often involve schedules for keeping the versioning up to date and the procedures to follow after the alarm has been sounded. For instance, if the IDS detects an attack pattern in the network traffic, certain IT personnel should be alerted, and certain procedures should be followed, such as trying to determine the source of the attack or locking down the system from the Internet. The policies that are put in place help to prevent the information systems and networks from being compromised.

Address-Based Restrictions

In addition to some of the possible security policies mentioned earlier, some network environments also have documented security policies stating that access to specific areas of the network is limited to specific IP addresses. Often these restrictions are placed to minimize security risks associated with ports or paths of communication from a system in the DMZ to the internal network. For example, only Server1 in the DMZ can communicate directly with Server2 using port 1433. However, some organizations have even restricted remote administration to specific IP addresses within the internal network.

Authentication

Authentication defines how users are to be identified. It is also the primary authentication mechanism. After a user or system is identified, authentication must occur in Windows Server 2003. Authentication is the process in which a system or user verifies the identification of the other. In other words, the users prove that they are really who they say they are. This is similar to presenting a cashier with a credit card and the cashier asking for a driver's license or other photo ID.

Windows Server 2003 offers several different authentication mechanisms and protocols, including

  • Kerberos

  • .NET Passport

  • Digest

  • Secure Sockets Layer (SSL)

  • HTTP

  • S/MIME

These protocols should be chosen based on the features that you need. For example, for authenticating to Active Directory in a LAN environment, Kerberos is probably the preferred method.

As best practice, security policies relating to authentication should specify the following:

  • The authentication mechanisms required for performing certain tasks. For example, all traffic to the development Web site must use certificate authentication before establishing an SSL connection.

  • The number of authentication factors (that is, the number of authentications) required before accessing a specific system or group of systems.

Authorization

After a user is authenticated, anytime that user requests access to a resource such as a file, folder, share, printer, and so on, Windows Server 2003 checks to see whether the user has the necessary access rights to access and use that resource. For instance, a user can use a Kerberos session ticket to gain access to many different resources or objects. If the user has the necessary rights, that resource can then be accessed and used. This process is called authorization.

Authorization uses access control methods to determine whether a user has the proper rights to access resources. These access control methods are access control lists (ACLs) and roles.

The New Technology File System (NTFS) is one of the primary ways to set access control; it can be used to gain control over authorized and unauthorized access by assigning permissions. It also incorporates the Encrypting File System (EFS), which can be used to further tighten security by encrypting sensitive and confidential information.

The following are some best practices for using NTFS that can also be incorporated into a security policy:

  • Remove the Everyone group from permissions.

  • Use groups instead of individual users when configuring access controls.

  • Use the least-privilege principle so that users can access only the information that they need.

  • Ensure that administrators have full control on all files, folders, and shares unless the organization specifically dictates otherwise.

  • Allow only administrators to manage resources.

Base Installations

When organizations build servers from scratch, typically the configurations are built inconsistently. In other words, some file and print servers may have IIS, Remote Desktop for Administration, various NTFS permissions, and more, whereas other servers do not. From an administration, maintenance, troubleshooting, or security point of view, such configurations can be a nightmare. Each server must be treated individually, and administrators must try to keep track of separate, incongruent configurations.

Base installation security policies and server build documentation help to create a standard baseline for how a specific type of server is built and the type of security that is applied. They can contain step-by-step instructions on how to build different types of servers without sacrificing security. From this, all administrators have a common ground or knowledgebase of configuration information, including security configurations, which can save time when administering, maintaining, and troubleshooting.

PKI

A Public Key Infrastructure (PKI) is an infrastructure model that manages the creation and distribution of public key certificates. Public key cryptography used to secure (encrypt and verify) communication for a wide number of IT services such as HTTP traffic, VPN connections, network authentication, secure email exchanges, etc. PKI facilitates a web of trust to be established between members of a PKI and their public keys. This web of trust is used by members to provide authentication, identity verification, and confidentiality for intra-party communications.

A CA stores the private and public keys and is responsible for issuing and signing certificates. These certificates are digitally signed agreements that bind the value of the public key with a distinct private key. Certificates typically contain information on the name of the user or service, the time in which the certificate is valid, CA identifier information, the public key value, and the digital signature.

Monitoring Tools

Protecting the network environment with various security policies and mechanisms is, without question, necessary. However, monitoring is also key to enforcement and identifying security policy violations. For instance, all the security policies and mechanisms can be in place, but without monitoring, there is no way to identify and determine whether they are effective.

Some common monitoring tools found within an organization include syslog, SNMP, traffic sniffers, and IDS. The most common Windows Server 2003 monitoring tool is the Event Viewer. The Event Viewer captures audited events such as account logon, account management, directory access, object access, policy change, and more. By default, initial auditing parameters are set to audit successful account logon events. Moreover, logging is configured to use up to 128MB of disk space before overwriting events.

Note

New logon type events can be monitored, including cached logons and remote interactive (Terminal Services) logons.

Application logs are also commonly reviewed for security purposes. Log files are usually generated by services and applications, and the level of detail can often be configured to provide just general information up to the maximum amount of detail. The level of detail that can be provided and the configuration options vary. When you're configuring these options, keep in mind the amount of disk space required as well as how this information will be reviewed.

Tip

It is highly recommended that you consider using Microsoft Operations Manager (MOM) to monitor and manage the Windows Server 2003 network environment. It can consolidate security-related events and provide a convenient, centralized location to review security information on multiple Windows Server 2003 systems.

Auditing Tools

Numerous security stress-testing tools are available from third-party vendors. Many have very specific functionality such as port scanning, password cracking, buffer overflow identification, and more. For example, LC4, formerly known as Lophtcrack, can be used as a password-auditing tool to discover weak passwords, but it's not designed to uncover other vulnerabilities.

When choosing a third-party security tool, you must carefully choose your target area before conducting a stress test.


Windows Server 2003 Security Policy Toolbox

To ensure policies are adhered to organizations must enforce their security policies. In addition to the preceding general technology controls Windows Server 20003 has integrated many different tools to enforce security policies throughout an organization's Windows based systems.

Certificate Services

Windows Server 2003 has the capability to act as a certificate authority (CA). This service in Windows is called the certificate services and is available on Windows Server 2003 Standard Edition, Enterprise Edition, and Datacenter Edition.

Note

Windows Server 2003 Enterprise Edition or Datacenter Edition is required to configure version 2 certificate templates for auto-enrollment.

To install Windows Server 2003 certificate services, do the following:

1.
Choose Start, Control Panel and then select the Add or Remove Programs icon.

2.
Select Add/Remove Windows Components to display the Windows Components Wizard window.

3.
Check the Certificate Service box. When you see a warning message, click Yes to proceed. Click Next to Continue.

4.
Choose the type of CA to install. You can choose from the following options:

  • Enterprise Root CA This CA requires Active Directory, and is the topmost level of the certificate services hierarchy. It can issue and sign its own certificates.

  • Enterprise Subordinate CA This type of CA is subordinate to the enterprise root CA. It requires Active Directory and can obtain certificates from an enterprise root CA.

  • Standalone Root CA This CA is the topmost level of the certificate services hierarchy and can issue and sign its own certificates. Standalone CAs do not require Active Directory.

  • Standalone Subordinate CA Similar to the enterprise subordinate CA, this CA is subordinate to the standalone root CA.

5.
Checking this box and then clicking Next allows you to select the cryptographic service provider (CSP), hash algorithm, and key pair configuration as shown in Figure 15.1.

Figure 15.1. Customizing the CA.

[View full size image]

6.
Identify the CA by entering the appropriate common name. You can also set how long the CA is valid (the default is five years). Click Next to continue.

7.
Verify the location of the certificate database, logs, and shared folder. Click Next to continue.

8.
Click Finish to complete the CA creation.

Note

Windows Server 2003 contains a command-line utility called certutil.exe that can provide a wealth of information about a CA and certificates. Microsoft touts this as a powerful troubleshooting tool and rightly so. Its many capabilities include, but are not limited to, verifying certificates and services, displaying certificate services configuration information, re-associating private keys with the proper certificate, publishing a certificate revocation list, and revoking certificates. As you can see, however, this tool is also very useful for keeping security policies enforced and in the proper configuration.

Security Configuration and Analysis

Windows Server 2003's integrated Security Configuration and Analysis tool is used to compare the current security configuration against a database. This database uses one or more predefined security templates. If more than one security template is used, the settings from each security template are merged, which may result in a combination of security configurations. If a conflict occurs between the database and the last-applied security template, the last security template takes precedence.

Note

The Security Configuration and Analysis tool displays indicators on each security configuration as to how it ranks when compared to the analysis database. For instance, a red X indicates that values between the database and the current configuration do not match.

To begin using the Security Configuration and Analysis tool, do the following:

1.
Choose Start, Run and type MMC. Click OK.

2.
Select File, Add/Remove Snap-In.

3.
Click the Add button and choose Security Configuration and Analysis. Click the Add button in the Add Standalone Snap-in page.

4.
Click Close and then OK to return to the Microsoft Management Console.

5.
Click Security Configuration and Analysis in the left pane. If this is your first time using the tool, you'll see instructions on how to open a Security Configuration and Analysis database or create a new one.

6.
If you want to create a new database, right-click Security Configuration and Analysis in the left pane and select Open Database.

7.
Browse to the location you want to store the database and then type in its filename.

8.
Click Open to create the new database.

9.
In the Import Template dialog box, choose which security template to use and then click Open. In this example, use setup security.inf.

10.
Select Action, Analyze Computer Now.

11.
In the Perform Analysis window, specify the location and name of the log file you want to use. Click OK when you're done.

12.
After the Security Configuration and Analysis tool finishes analyzing the system against the analysis database, you can browse and review the security configurations, as shown in Figure 15.2. At this point, you can either selectively configure security settings or select Action, Configure Computer Now to set the security settings.

Figure 15.2. Using the Security Configuration and Analysis tool to determine security configurations.

[View full size image]

Security Configuration and Analysis is a great tool for standardizing Windows Server 2003 security throughout the network. It is also very useful for ensuring that security configurations are set properly. Use this tool at least every quarter and on new systems to keep security policies enforced.

Microsoft Baseline Security Analyzer

The Microsoft Baseline Security Analyzer (MBSA) is a tool that identifies common security misconfigurations and missing updates through local or remote scans of Windows systems. MBSA scans either a single Windows system or a group of Windows systems and obtains a security assessment, as well as a list of recommended corrective actions. Furthermore, administrators can use the MBSA tool to scan multiple functional roles, such as a Microsoft SQL Server or Exchange system, of a Windows-based server on the network for vulnerabilities to help ensure systems are up-to-date with the latest security-related patches.

To run MBSA, do the following:

1. | Download the latest security XML file to use with MBSA. This file contains a list of current service packs and updates that should be applied to a system.
2. | Keep the default settings and scan the server(s).

Security Configuration Wizard

The Security Configuration Wizard (SCW) is a tool provided in Windows Server 2003 Service Pack 1 that can significantly improve a computer's or a group of computers' security. As the name implies, SCW is wizard-based, designed to determine the specific functionality required by the server. All other functionality that is not intended or required by the server can then be disabled. This reduces the computer's attack surface by limiting functionality to only that which is required and necessary.

SCW reviews the computer's configuration, including but not limited to the following:

  • Services SCW limits the number of services in use.

  • Packet filtering SCW can configure certain ports and protocols.

  • Auditing Auditing can be configured based on the computer's role and the organization's security requirements.

  • IIS SCW can secure IIS, including Web Extensions and legacy virtual directories.

  • Server roles and tasks The role (file, database, messaging, Web server, client, and so on), specific tasks (backup, content indexing, and so on), and placement in an environment that a computer may have is a critical component in any lock-down process or procedure. Some of the roles and tasks that are evaluated are illustrated in Figures 15.3 and 15.4. Application services are also evaluated from products such as Exchange Server 2003, SQL Server 2000, ISA Server, SharePoint Portal Server 2003, and Operations Manager.

  • IPSec SCW can be used to properly configure IPSec.

  • Registry settings After careful analysis, SCW can modify the LanMan Compatibility level, SMB security signatures, NoLMHash, and LDAP Server Integrity parameters based on down-level computer compatibility requirements.

Figure 15.3. Analyzing computer roles.

[View full size image]

Figure 15.4. Analyzing specific tasks.

[View full size image]

Caution

SCW is a very flexible and powerful security analysis and configuration tool. As a result, it is important to keep control over when and how the tool is used. Equally important is testing possible configurations in a segmented lab environment prior to implementation. Without proper testing, environment functionality can be stricken or completely locked.

SCW is used to assist in building specific security-related policies and to analyze computers against those policies to ensure compliance. In many ways, SCW can be considered a replacement for other Microsoft security-related tools that have already been mentioned in this chapter. For instance, SCW can take existing security templates created from the Security Configuration and Analysis tool and expand upon the restrictions to meet an organization's security policy requirements. In addition, SCW can create, edit, and apply system security policies to computers, integrate with Group Policy, and provide a knowledge base repository for system security policies.

Windows Rights Management Services

Windows Rights Management Services (RMS) is an unprecedented new feature that enables users to more securely create and control information. It gives the creator of the specific information control over the following:

  • What can be done with the information

  • Who can perform actions or tasks with the information, such as who can review or print a document or whether a message can be forwarded

  • The lifetime of the information meaning the time the information can be reviewed or used

RMS is intended to complement and co-exist with other security measures within an organization. Security mechanisms, policies, practices, and technologies should work seamlessly together to provide the most effective safeguarding of information and property, but at the same time, they should be as unobtrusive as possible to the end user. Therefore, RMS is not confined to a specific network or Web siteit extends beyond transport layer boundaries.

RMS further granularizes security for browsers and applications such as Microsoft Office 2003 that are WRM-aware by using encryption, Extensible Rights Markup Language (XrML)-based certificates, and authentication. Security administrators can establish RMS-trusted entities with users, groups, computers, and applications that are then used to assign security rights to information. The security rights are stored in a publishing license, which is encrypted along with the information. As information is requested, RMS validates credentials and usage rights.


Summary

Security policies shape a Windows Server 2003 network environment into a more controlled, more secure environment. Overall, they establish baselines that can more easily be enforced. Because security policies are based on business requirements more so than technical reasons, the entire organization must comply with these policies. The security policy tools examined in this chapter help to enforce the security policies and maintain the secured environment.


Best Practices

  • Executive management must define what security policies to put in place, the type of information to be protected, and the level of protection that is required.

  • Educate employees on the organizational security policies and the corresponding consequences for noncompliance on a periodic basis.

  • Review the Health Insurance Portability and Accountability Act (HIPAA) for health-care-related security policies at http://www.hipaa.org/.

  • Review the Gramm Leach Bliley Act (GLBA) for financial institutions at http://www.senate.gov/~banking/conf/.

  • Enforce security policies to make them effective.

  • Periodically perform security audits to define and strengthen security policies and practices.

  • Hire a security expert or firm to perform security audits on your infrastructure.

  • Create system-level security policies to provide baseline system specifications.

  • Define the primary authentication mechanism and the ways users are to be identified.

  • Identify which authentication mechanisms are required for performing certain tasks.

  • Practice defense-in-depth (DID) when constructing a security framework.

  • Use NTFS whenever possible.

  • Remove the Everyone group from permissions.

  • Use groups instead of individual users when configuring access controls.

  • Use the least privilege principle so that users can access only the information that they need.

  • Ensure that administrators have full control on all files, folders, and shares unless the organization specifically dictates otherwise.

  • Allow only administrators to manage resources.

  • Establish Windows Server 2003's software restriction policies. This service provides a transparent, policy-driven means to regulate unknown or untrusted applications.

  • Support only those applications that are approved and that are critical to the business.

  • Routinely update antivirus definition files to improve resilience against getting a virus.

  • Practice the least privilege principle to the entire organization.

  • Use Group Policy Objects (GPOs) to lock down the desktop so that users aren't given full access to the system. For example, disable the Run command or disallow use of the command prompt.

  • Thoroughly test Windows Server 2003 service packs and updates (especially those that are security-related) in a lab environment before deploying them in production.

  • Test and review application updates and patches to determine how they may affect application security and reliability.

  • Limit the number of applications a user has access to use.

  • Remove the username of the person who logged on last to the client machine. This keeps people from discovering other usernames and passwords.

  • Require users to change their passwords periodically.

  • Consider tightening password history, length, and strength requirements.

  • Mandate keeping documents on the file servers so that they are backed up every night.

  • Help alleviate concerns that documents aren't being backed up by using folder redirection.

  • Use the Security Configuration and Analysis tool to compare the current security configuration against a predetermined security requirement.


Part V: Migrating to Windows Server 2003

In This Part

CHAPTER 16 Migrating from Windows NT4 to Windows Server 2003

CHAPTER 17 Migrating from Windows 2000 to Windows Server 2003

CHAPTER 18 Compatibility Testing for Windows Server 2003


Chapter 16. Migrating from Windows NT4 to Windows Server 2003

In This Chapter

  • Migration Paths to Windows Server 2003

  • Preparing Windows NT4 Domains to Migrate to Windows Server 2003

  • Performing an Inplace Upgrade

  • Migrating Existing NT4 Domains to a New Windows Server 2003 Forest

  • Consolidating Windows NT4 Domains

  • Using Microsoft Active Directory Migration Tool

When you're migrating directly to Windows Server 2003 from Windows NT4, you must consider many factors while preparing and performing the migration. This chapter outlines the detailed tasks and reviews the different options to perform such a migration.

Before you begin, make sure that all preparation tasks such as your Active Directory design and pre-migration requirements covered in the "Preparing Windows NT4 Domains to Migrate to Windows Server 2003" section of this chapter have been identified and documented. Complete these areas to determine which migration path best fits your organization's migration needs.


Migration Paths to Windows Server 2003

The first decision to be made when migrating is to determine which type of migration strategy best fits your requirements and Active Directory design. Three migration paths are outlined in this chapter. Each migration path, described in the following list, is unique in characteristics and requires different tasks to complete. Therefore, each migration path should be planned in detail, scripted, and tested before you actually perform any migration tasks.

  • The first migration option is an inplace upgrade. This migration path is a direct upgrade of the Windows NT4 server operating system and domain to Windows Server 2003 and Active Directory.

  • The second option is to migrate the NT4 objects from an existing NT4 domain to a brand-new Windows Server 2003 forest and Active Directory.

  • The third option is to consolidate multiple existing Windows NT4 domains into a single Active Directory domain configuration.

Each domain migration path offers different characteristics and functionality. Before you continue, review each migration path and perform all preparation tasks to prepare your Windows NT4 environment to be migrated to Active Directory. Begin by determining the specific criteria for your migration, such as the time frame in which to complete the migration and your final Active Directory design. Understanding these key areas will assist you in determining which migration path is best for your organization.

Determining the Best Migration Path for Your Organization

With each specific migration path, there are different tasks and methods in which to prepare and complete a migration. There are also key business decisions and technical factors that can determine which path is best for your migration. Each of these paths and the benefits associated with them are outlined in the following sections.

Conducting an Inplace Upgrade

An inplace upgrade is very effective for organizations that want to maintain their existing Windows NT4 domain or multidomain models. Using this method allows you to effectively migrate from an existing domain or domains to Windows Server 2003 and Active Directory by upgrading the NT4 domain as it exists today into a Windows Server 2003 Active Directory domain. Because you are performing an inplace upgrade of the server operating system, each server system setting such as domain trusts and service accounts is preserved when the upgrade is complete.

The most compelling reasons for organizations to use this method are as follows: After the server operating system is upgraded to Windows Server 2003, the Active Directory Installation Wizard will also migrate and upgrade all existing Windows NT4 domain security principles such as domain users, groups, and permissions to Active Directory. This is considered the simplest model because no additional tools or third-party software is required to complete the migration. Also, after the inplace migration, desktops and laptops in the organization do not need to be touched because they will effectively remain in the same Windows domain as they were in NT4. This factor is significant for organizations that want to migrate but do not want to touch every single desktop after the migration. After proper planning and testing, some organizations have actually conducted an upgrade from Windows NT4 to Windows Server 2003 on a Friday night, with no dramatic impact on users or operation of the network.

Note

The inplace upgrade method of migration from Windows NT4 to Windows 2003 has proven to be the preferred method of migration for most migrations from NT4. Because the inplace upgrade migration maintains user accounts, computer accounts, security principles, user profiles, and other key network information, this migration method has the least (if any) impact on users, thus making it the cleanest migration method. Inplace upgrades do not require existing domain controller hardware to be upgraded, however, it only implies that the domain itself can be upgraded inplace.

Migrating an Existing Windows NT4 Domain to a New Windows Server 2003 Forest

As organizations grow or business needs change, many companies are looking for an effective method of changing their existing Windows NT4 domain model. Migrating an existing Windows NT4 domain to a new Windows Server 2003 forest allows administrators to design and install a new Windows Server 2003 Active Directory forest without interrupting existing Windows NT4 network connectivity.

When you use the Active Directory Migration Tool (ADMT) to migrate Windows NT4 domain security principles and resources to Active Directory, existing Windows NT4 security principles can then be migrated to organizational units and child domains within the newly structured Active Directory forest, as shown in Figure 16.1.

Figure 16.1. Migrating existing domains to a new Windows Server 2003 forest.

By taking advantage of the enhanced functionality of Windows Server 2003, Active Directory can be integrated with Windows NT4 domains by using domain trusts and permissions. This functionality makes this option very effective for larger organizations and enables administrators to migrate security principles incrementally over time while still maintaining connectivity to the same shared network resources. This means users in the Windows NT4 domain can access the same resources as users who have been migrated to Active Directory without interruption to day-to-day operations.

This migration path also allows administrators to further organize and structure a new domain by allowing objects to be moved between Active Directory domains and organizational units after they have been migrated. All these tasks can be completed while still maintaining connectivity between Windows NT4 and Windows Server 2003, further enhancing your ability to build a new domain model without the need to create new users and computer accounts as well as new network resources.

Is a New Forest Cleaner than an Inplace-Upgraded Forest?

One of the reasons why organizations put forth the effort of building a brand-new Active Directory forest (instead of doing an inplace upgrade of their existing Windows NT4 domain) is that they believe the brand-new forest will be cleaner than an inplace upgrade. Although no old objects are migrated to the new Active Directory forest, there are ways to clean up an inplace-upgraded domain so that it ends up being just as clean as a brand-new forest. The big advantage to performing an inplace upgrade is that it minimizes the need to manually create each user and computer object in the new forest, and eases the process of ensuring that user profiles, favorites, security settings, and other unique settings are copied to the new forest.

The process of cleaning up an inplace-upgraded domain simply involves deleting all unused migrated objects. The administrator then builds a brand-new global catalog server and moves the FSMO roles to the new global catalog server. Only existing objects will be migrated to the new server as old objects are not moved. This creates a new global catalog server that has no legacy objects, making it just as clean as if a global catalog server was created from scratch with objects manually added to the server.

Another argument against an inplace upgrade is the resultant forest name. Many administrators incorrectly believe that when they do an inplace upgrade, they are stuck with the same forest name as their existing Windows NT4 domain name. When an inplace upgrade is conducted on a primary domain controller, the administrator is asked for a fully qualified DNS name for the new forest. An organization with a Windows NT4 domain name of CompanyX can do an inplace upgrade to a Windows 2003 Active Directory forest name of something completely different, such as companyabc.com. The old CompanyX is a NetBIOS name, whereas forests in Active Directory use DNS names.

Organizations need to consider whether the real benefits of building a new forest outweigh the extreme cost, effort, time, and user interruption that a clean forest build creates. Most arguments against an inplace upgrade can be cleared up as misperceptions of what can and cannot be done in the upgrade process, giving an organization better options for migrating its networks.

Consolidating Multiple Windows NT4 Domains to Active Directory

The third migration path allows an organization to migrate to Windows Server 2003 and Active Directory using all the functionality and integration capabilities of the first and second migration paths. When you consolidate domains, your organization can perform an inplace upgrade while maintaining selected existing Windows NT4 domains. Other existing NT domains can then be consolidated into the new Active Directory domain or domains within the forest. Domains can even be migrated and consolidated into organizational units, allowing for more granular administration. When security principles are migrated using the Active Directory Migration Tool, this option allows organizations to consolidate and migrate additional domains incrementally while maintaining selected existing domain infrastructures.

This option is effective for organizations that have acquired other companies and their networks and still want to maintain their original domain model. When you consolidate domains, effectively you are upgrading a domain or domains within the existing domain model. After the upgrades are completed, you can then begin consolidating and restructuring domains by migrating security principles into new organizational units with the forest root or child domains in the new Active Directory forest. Additional account and resource domains can then also be consolidated within the newly structured Active Directory forest.


Preparing Windows NT4 Domains to Migrate to Windows Server 2003

Now that you have an understanding of the migration requirements and the path in which you are going to migrate to Windows Server 2003 and Active Directory, the next step is to begin preparing your existing network infrastructure and Windows NT4 domain to be migrated to Windows Server 2003 and Active Directory.

Whether you are implanting a new Windows Server 2003 Active Directory domain or upgrading existing Windows NT4 server operating systems and domains to Windows Server 2003, you must consider several steps regarding hardware and software before you begin your migration. Performing these steps will prevent avoidable problems in areas such as meeting Windows Server 2003 family hardware requirements, ensuring Windows Server 2003 hardware and software compatibility, and planning server hardware configuration to optimize server performance. The following section addresses these specific areas and identifies the tools available to help prepare your server hardware and software for a successful migration to Windows Server 2003.

Hardware and Software Compatibility

Before migrating servers to Windows Server 2003, you must determine whether your Windows NT4 server hardware and Windows NT4 serverbased applications are compatible with the Windows Server 2003 family operating systems. To test each server for compatibility, use the Microsoft Compatibility Check tool available on your Windows Server 2003 installation CD-ROM.

Note

You can also review the Windows Server 2003 family hardware and software compatibility list on the Microsoft Web site. Windows 2003 compatibility information can be found at http://www.microsoft.com/hcl.

The Compatibility Check tool can be run from the Windows Server 2003 setup CD-ROM. It does not require you to begin installing or upgrading the server operating system to run the tool.

You can choose from two methods to run the Compatibility Check tool. You can use the autorun feature built into your server system to launch the Windows Server 2003 Setup screen. If your server system does not support the autorun feature, or it has been disabled, you can run the utility from a command prompt or Windows Run option. To run the Compatibility Check tool at the prompt, type d:\i386\winnt32/checkupgradeonly, where d: represents the CD-ROM drive letter.

Each method allows you to launch the Windows Server 2003 Compatibility Check tool. Be sure to run this tool before upgrading or installing Windows Server 2003 and Active Directory. Replace any incompatible hardware and upgrade any software as required to ensure proper functionality when your migration is complete.

Reviewing Hardware and Software Requirements

One of the most important steps before migrating is to ensure that the existing server hardware and server operating systems that you plan to migrate meet the minimum requirements for installing the Windows Server 2003 family products. Ensuring that the server hardware meets these requirements and planning for the addition of server hardware resources such as memory can assist you in ensuring that server performance will be adequate when your migration is complete. The following sections list the minimum requirements and recommended hardware and software requirements for performing an upgrade or clean installation of Windows Server 2003 family products.

Operating System Requirements

Most Windows NT4 network installations contain multiple versions of the NT4 operating system. Each operating system type must meet the minimum requirements for upgrading or migrating to the Windows Server 2003 family.

The server operating system requirements include the following:

  • Windows NT 4.0 Service Pack 5 or higher

  • Windows NT 4.0 Terminal Server Edition with Service Pack 5 or higher

  • Windows NT 4.0 Enterprise Edition with Service Pack 5 or higher

Server Hardware Requirements

Before you install Windows Server 2003, review your existing server hardware to ensure each system meets the minimum requirements for installing the Windows Server 2003 family server operating system. Also, plan your server hardware configurations and upgrades based on server roles. Be sure to plan for adequate hardware resources to ensure optimal performance based on each server role:

  • For x86-based systems Windows Server 2003 supports Intel's Pentium and Celeron, AMD K6, Athlon, and Duron processors at 133MHz and higher. For best performance, Microsoft recommends a minimum speed of 550MHz. The minimum supported memory for installing Windows Server 2003 is 128MB of RAM. Review each server role and plan memory requirements to ensure best performance. Microsoft recommends 256MB of memory.

  • For Itanium-based systems A minimum processor speed of 733MHz is recommended, as is a minimum of 1GB of RAM.

Migrating Windows NT4 Volumes, Mirrors, and Stripe Sets

Often when Windows NT4 servers were installed without hardware fault-tolerant equipment, the Windows NT4 Disk Manager was used to create volume sets, mirrored sets, stripe sets, and stripe sets with parity. Because the Windows Server 2003 operating system does not support Windows NT4 Disk Manager configurations, you must modify software-based disk configurations before performing an inplace upgrade to Windows Server 2003. Perform the tasks described in the following sections for each configuration before continuing to upgrade any Windows NT servers.

Mirrored Volumes

If you used Windows NT4 to create a mirrored set, before upgrading to Windows Server 2003, you must break the Windows NT4 mirrored set.

Note

By breaking the mirror, you do not lose any data; however, it is always best practice to back up the server before performing any disk maintenance or reconfiguration processes.

Volume Sets, Striped Sets, and Striped Sets with Parity

If the server you are going to upgrade has been configured using Windows NT4 volume sets, stripe sets, or stripe sets with parity, you must delete the sets and configure new drive configurations with fault tolerance before you can conduct an inplace upgrade.

Caution

Deleting a volume set, stripe set, or stripe set with parity deletes all the data from the volume. Be sure to back up all server data before deleting any type of volume or stripe sets.

Because the inplace migration from Windows NT4 to Windows Server 2003 of a volume set, stripe set, or stripe set with parity requires the server hardware to be reconfigured, it is recommended that you build a brand-new Windows NT4 primary domain controller (PDC) and conduct the inplace upgrade on the new system. By adding a new domain controller on the network that does not have unsupported volume and stripe sets, you can conduct the inplace upgrade on this new system without having to bring the old system offline. When the new system is promoted to become a Windows NT4 primary domain controller, the old server will become a backup domain controller (BDC), and all the information stored on the old system will remain intact.

Installing and Configuring Services for Compatibility with Windows Server 2003

Migrating network services has always been one of the most challenging areas for administrators during any type of migration. When a Windows NT4 domain controller is upgraded in place, all network services are also upgraded to Active Directory, and Windows Server 2003 eliminates the need to install new network services to maintain connectivity during a migration. However, network services such as Dynamic Host Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), and Domain Name System (DNS) must be considered before you upgrade or migrate to Windows Server 2003 and Active Directory regardless of which migration method you use.

The area to focus on is planning, creating your migration script, and planning for a move or installation of services so that your migration is uninterrupted by failure of server-to-server connectivity as well as client-to-server connectivity. If you are migrating to Windows Server 2003 and Active Directory, network services such as DNS and DHCP must be used to maintain coexistence between domains. Ensure that your migration plan includes migrating these network services and avoids interruptions by migrating vital network services in the first phases of your migration.

Preparing an NT 4.0 SAM Database

The preparation of a Windows NT 4.0 SAM database is a relatively simple, two-step process. To prepare a Windows NT4 SAM database for a migration to Windows Server 2003, perform the following steps:

1. | Remove unused security principles before upgrading a domain or migrating Windows NT4 security principles to Windows Server 2003 and Active Directory. It is a good practice to remove unwanted user, group, and computer accounts from the Window NT4 SAM database. By cleaning up the SAM database, you can then focus your migration on actual accounts.
2. | Address duplicate and similar account names when you are consolidating domains. Review each Windows NT4 domain for similar or duplicate account names, group names, and resources. As you begin migrating Windows NT4 security principles to Windows Server 2003 and Active Directory, understand that these potential conflicts will assist you in configuring the Active Directory Migration Tool to resolve these naming conflicts.

After you remove unwanted Windows NT accounts and review each existing domain, it is a good practice to replicate the clean SAM database to all domain controllers with the Windows NT domain. Use the Server Manager console in your Windows NT Administrator Tools to replicate the domain's primary domain controller and SAM database to all backup domain controllers within the domain.


Performing an Inplace Upgrade

This section will guide you through the steps to migrate a Windows NT4 domain directly to Windows Server 2003 and Active Directory.

Three areas will be covered in this section:

  • Upgrading primary domain controllers When you perform an inplace upgrade, the first server in the Windows NT domain to upgrade is the primary domain controller. When you upgrade the primary domain controller, all Windows NT domain security principles such as user accounts, domain groups, permissions, and network services are also upgraded to Windows Server 2003 and Active Directory.

    Note

    Before you begin an inplace upgrade of a domain, it is a good practice to synchronize the primary domain controller and backup domain controllers. After the SAM database is copied to all backup domain controllers, you should remove one of the backup domain controllers from the domain in case you need to roll back to Windows NT. This BDC will contain a copy of the domain's SAM database and can be promoted to a primary domain controller as a means of recovering the original Windows NT4 domain and SAM database.

  • Upgrading backup domain controllers After the primary domain controller is upgraded, the next step is to complete an upgrade of the remaining backup domain controllers. As a migration process, a Windows NT4 backup domain controller does not need to be upgraded in place. The system that will be a Windows 2003 domain controller should just be installed from scratch and then promoted with the DCPROMO command to become a Windows Server 2003 domain controller.

  • Upgrading domain member servers Each of the domain member servers can be upgraded at any time. As with domain controllers, migrate each member sever based on importance and network role. When you're performing an inplace upgrade to Windows Server 2003 and Active Directory, you must install Microsoft's DNS. Each server's TCP/IP property should be modified to include the TCP/IP address of the Active Directoryintegrated DNS.

Upgrading the Windows NT4 Primary Domain Controller

To begin performing an inplace upgrade, do the following:

1. | Insert the Windows Server 2003 installation CD-ROM into the CD-ROM drive of the domain's primary domain controller. If your server has autorun enabled, the Windows Server 2003 Setup Wizard screen will appear. If your server does not have autorun enabled, you can launch the Windows Server 2003 Setup Wizard by running the Setup.exe program from the Windows Server 2003 CD-ROM.
2. | On the Welcome to Windows Server 2003 Family page, select Install Windows Server 2003 to begin upgrading the primary domain controller to Windows Server 2003 and Active Directory. This step will launch the Windows Setup Wizard, which will guide you through the setup process.
3. | On the Welcome to Windows Setup page, select the installation type you want to perform; in this case, select Upgrade (Recommended). This will begin the upgrade of the Windows NT4 server operating system to Windows Server 2003 and Active Directory. Click Next to continue.
4. | On the Licensing Agreement page, use the scrollbar to read the Microsoft licensing agreement. This page requires you to select one of the options. After reading the Licensing Agreement page, select I Accept This Agreement and click Next to continue.
5. | Your copy of Windows Server 2003 should have a license key that came with the Windows Server 2003 CD-ROM Software. Enter the 25-character product code and click Next.
6. | Review the Report System Compatibility to identify any issues with the inplace upgrade by clicking the details button. Select Next to continue.

The Windows Server 2003 Setup Wizard will now begin the installation of Windows Server 2003. The wizard will begin copying necessary files to your computer's hard drive. You can monitor the upgrade progress from the progress bar in the lower-left corner of the installation screen. After the Windows Server 2003 Setup Wizard copies the files, the server will automatically restart.

Upgrading to Active Directory

After the Windows Server 2003 Setup Wizard upgrades the operating system to Windows Server 2003, the system will restart automatically and begin running the Active Directory Installation Wizard, as shown in Figure 16.2.

Figure 16.2. Active Directory Installation Wizard.

To install Microsoft's Active Directory, do the following:

1. | At the Welcome screen, click Next. This will upgrade the existing Windows NT4 domain and domain security principles to Active Directory. Note Choosing this option will maintain the existing NT4 domain and upgrade all domain security principles directly to Active Directory. All NT4 user accounts, domain groups, and computer accounts will automatically be upgraded into the new Active Directory domain.
2. | Review the Operating System Compatibility screen; if you agree, select Next to continue.
3. | At the Create New Domain page, select the option to create a new domain in a new forest and then click Next. As mentioned earlier, Active Directory requires that the domain name system be installed before the AD installation can continue. Because this is an upgrade from an existing NT domain, you can assume that Microsoft DNS has not been installed on your network.
4. | If your network has a DNS server compatible with Windows Server 2003 and Active Directory, select Yes, I Will Configure the DNS Client.
5. | If there is no DNS server on your network and you intend this server to be the first DNS server within the new Active Directory domain, select No, Just Install and Configure DNS on This Computer. Then click Next to continue.
6. | On the New Domain page, type your domain's DNS name. This should be the domain name you selected in Chapter 5, "Designing a Windows Server 2003 Active Directory," as your Active Directory fully qualified DNS name. Click Next to continue. For a continuation of this process, refer to the next section.
7. | After the installation of Active Directory is complete, review the Active Directory Users and Computers MMC snap-in to ensure that all security principles have been upgraded properly.

Setting Forest Functionality Levels

Forest functionality levels deal with the integration of Windows NT4 and Windows 2000 domain controllers into Windows Server 2003 environments. The option that you select depends on whether you are planning to install additional Windows NT4 or Windows 2000 domain controllers in your new domain. The option Windows Server 2003 Interim Forest is used for additional Windows NT4 domain controller interoperability, whereas the Windows 2000 Domain option allows for Windows 2000 domain controllers to be added in the future.

For this installation, assume that no Windows 2000 server will be installed in the new Windows Server 2003 domain. Now pick up where you left off in the preceding section:

8. | Select the Windows Server 2003 option and click Next.
9. | On the Database and Log Folders page, you can select the location paths for the Active Directory database and database log files. Unless your design requires the Active Directory database and log files to be placed in a different location, choose the default path and click Next. Ensure that the server you are upgrading has sufficient disk space to host Active Directory databases.
10. | If your server configuration does not call for you to move the SYSVOL folder, select the default location and click Next to continue. The SYSVOL folder is the location for storing a copy of the domain's public files. These public files are replicated and used for domain information on all domain controllers within the Active Directory domain.
11. | On the Permissions page, select Permissions Compatible Only with Windows 2000 or Windows Server 2003 Operating Systems and click Next. You select this option because this migration path is an upgrade from Windows NT4. Therefore, you don't need to configure Active Directory with permissions that are compatible with Windows NT domains.

The following section provides the next steps in the Windows Server 2003 inplace upgrade.

Applying Security to the Directory Services Restore Mode

As a continuation from the preceding section, the next steps in the process are the following:

12. | Apply security to the Directory Services Restore Mode by assigning a password to the Directory Service Restore Mode account. This password should be documented in a secure location in case a recovery of the server is required. When you're configuring the account name and password, keep in mind that each Windows Server 2003 server within Active Directory will have its own unique Directory Services Restore Mode account. This account is not associated with the Domain Administrator account or any other Enterprise Administrator account in Active Directory. Enter the account name and password and then click Next.
13. | Use the scrollbar to review the server configuration summary page before you complete the installation. Ensure that the configuration information is correct. If changes are required, use the Back button to modify the server configuration. If the installation summary is correct, click Next to continue.

Caution

When you click Next to continue, the installation of Active Directory and Microsoft DNS will begin, and no modifications can be made thereafter.

Before choosing Finish and completing the inplace upgrade, review the Windows Server 2003 Setup Wizard information. This information can identify whether your installation experienced any errors.

Note

It is a good practice to review the server event and system logs after completing any upgrade. Review each log and identify errors and warnings that can potentially affect the stability of the server you are upgrading and that can cause problems with domain authentication.

Also review the Active Directory Users and Computers MMC snap-in to ensure that all security principles have migrated successfully to Windows Server 2003 and Active Directory.

Migrating Backup Domain Controllers and Domain Member Servers

After the domain's primary domain controller upgrade is complete, the next step is to upgrade the remaining network backup domain controllers and member servers to Windows Server 2003 and Active Directory.

Note

Before you begin, review the backup domain controller's and member server's application and system logs to identify issues that can affect the progress of your migration.

When you're performing an upgrade of Windows NT4 backup domain controllers and domain member servers, the Active Directory Installation Wizard allows you to change the server's domain membership type or server roles.

For example, an existing NT BDC can be migrated to Windows Server 2003 and Active Directory as a member server or a domain controller. The same is true for Windows NT4 domain member servers.

When you begin this phase of the upgrade, determining which servers to upgrade first is important. Your migration script should include the order in which each BDC and member server will be migrated as well as the server role in which the BDC or member server will play after it is upgraded.

As a rule, you should first consider upgrading backup domain controllers that host network services such as DHCP and WINS. When you migrate vital network services, network downtime and interruption of server-to-server communications are minimized.

Starting the Domain Controller/Member Server Upgrade

The first step in this phase is to insert the Windows Server 2003 installation CD into the CD-ROM drive of the backup domain controller. If your server has autorun enabled, the Windows Server 2003 Setup screen will appear. The procedure assumes that the upgrade is being performed on a domain member server.

If your server does not have autorun enabled, you can launch the Windows Server 2003 Setup Wizard by running the Setup.exe program from the Windows Server 2003 CD-ROM. Then follow these steps:

1. | On the Welcome to Windows Server 2003 Family page, select Install Windows Server 2003. This step will launch the Windows Setup Wizard, which will guide you through the setup process.
2. | On the Welcome to Windows Setup page, select the installation type; in this case, select Upgrade (Recommended). This will begin the upgrade of the Windows NT4 operating system to Windows Server 2003. Click Next to continue.
3. | On the Licensing Agreement page, use the scrollbar to read the Microsoft licensing agreement. This page requires you to select one of the options. To continue, select I Accept This License Agreement and then click Next.
4. | Each copy of Windows Server 2003 comes with its own 25-character license key. Enter the 25-character product code and click Next.

The Setup Wizard will begin upgrading the Windows NT4 operating system to Windows Server 2003 by copying necessary files to the server's hard drive. You can monitor the inplace upgrade progress from the progress bar in the lower-left corner of the screen. After the wizard copies files, the server will automatically restart.

Upgrading the Windows NT4 BDC to a Windows Server 2003 Domain Controller

Installing Microsoft's Active Directory on a Windows NT4 backup domain controller or member server differs from upgrading the primary domain controller. The installation of Active Directory on BDCs and member servers requires only that you configure the server role in which each server will play after the upgrade is complete.

After the Server Installation Wizard finishes upgrading the operating system to Windows Server 2003, the system will restart automatically and begin running the Active Directory Installation Wizard. To continue the upgrade process, do the following:

1.
At the Welcome screen, click Next to begin the installation of Active Directory.

2.
Select Member Server as the server role, as depicted in Figure 16.3, and then click Next to continue. The Active Directory Installation Wizard will install the domain controller or member server into the new Active Directory domain.

Figure 16.3. The Server Role Configuration page.

3.
Add the TCP/IP address of the Active Directory DNS server in the Network Connections property page of Windows Server 2003. After you add the DNS server address, click Next to continue. This scenario assumes that no DNS server address has been configured prior to performing an inplace upgrade of the organization's primary domain controller. If the BDC being upgraded has not been configured with the TCP/IP address of the new domain's DNS server, the Configure Domain Name Service Client configuration page will open.

4.
On the Network Credentials page, enter the name and password of the Domain Administrator account with permissions to join new computer accounts to the domain. Click Next to continue.

5.
On the Administrator Password page, you can assign a new local administrator password to the new Active Directory server. Enter a new password and click Next.

6.
Use the scrollbar to review your server configuration summary and ensure that the configuration you have selected is correct. Click Finish to close the Active Directory Installation Wizard and finish the inplace upgrade.

7.
After the server joins the Active Directory domain, restart the server to complete the inplace upgrade and apply changes to the new Active Directory member server.

Review the server's Event Viewer application and system logs to identify any errors with your upgrade. Resolve any issues identified to maintain server health and network connectivity before continuing the upgrade of any additional domain servers.


Migrating Existing NT4 Domains to a New Windows Server 2003 Forest

The second migration option allows an organization to migrate the objects (users, computers, groups, and so on) from an existing Windows NT4 domain or domains into a brand-new Active Directory forest.

After installing and configuring a new Windows Server 2003 Active Directory domain with pre-Windows 2000 permissions and creating a domain trust to integrate Windows NT4 domains with Active Directory domains, you can then use the Active Directory Migration Tool to migrate any and all Windows NT4 security principles to Active Directory domains and organizational units. By using domain trusts to provide coexistence between Windows Server 2003 and Windows NT4 resources, organizations can then migrate security principles incrementally over time and still maintain shared resources located on each domain.

When you use the Active Directory Migration Tool to restructure domains, all NT4 security principles are copied or cloned from the Windows NT4 domain and placed into Active Directory. When NT4 security principles are cloned, the source domain is left completely in place and uninterrupted, allowing you to easily roll back to the previous domain if required.

Installing and Configuring a New Windows Server 2003 Forest and Domain

Installing a new domain requires the installation of a new domain controller and Microsoft's Active Directory. After you install a new Windows Server 2003 system, you can then use the DCPROMO command to begin installing AD. To begin the Active Directory Installation Wizard, do the following:

1.
Choose Start, Run and then type DCPROMO. This will open the Welcome to the Active Directory Installation Wizard screen and guide you through the installation of a new Windows Server 2003 forest. Review the Operating System Compatibility screen; if you agree, select Next to continue.

Note

A migration to a brand-new forest allows organizations to upgrade domain hardware and install Windows Server 2003 on brand-new server equipment. Before beginning the installation of Windows Server 2003 and Active Directory, run the Compatibility Check tool to review the server hardware requirements. Then review your Active Directory design and complete the installation and configuration of all domain hardware and domain objects before beginning the migration of Windows NT4 security principles.

You can use the Active Directory Installation Wizard to install the first domain controller in the new Active Directory forest. You can also use it to install additional domain controllers as well as child domains after the first domain controller installation is complete.

2.
At the Welcome screen, click Next to begin installing the new Active Directory domain. Because this installation is a new domain and it is the first server in the domain, on the Domain Controller Type page, select Domain Controller for a New Domain. This option will create a new Active Directory forest and configure the first domain controller in the new domain.

3.
To create the new domain forest, on the Create New Domain page, select Domain in a New Forest and click Next to continue.

4.
On the Install and Configure DNS page, you can determine how DNS will be installed within the new Active Directory domain. This page can be used to install DNS on the server or configure the upgrade to use a different DNS server on the network. Because this is the first domain controller in the new forest, select No, Just Install and Configure the DNS Server on This Computer. Choosing this option will install Microsoft DNS on the new domain controller and modify the server's TCP/IP properties to use the new DNS installation for name resolution.

5.
Enter the fully qualified DNS name of your new Active Directory domain. This DNS name is not the same as the existing Windows NT domain name and must be unique to any domain names on your network. Click Next to continue.

6.
Enter the NetBIOS name information and then click Next. The NetBIOS Domain Name is the name you want Windows NT4 domains to use when identifying your new Active Directory domain. It is usually the same name as your new domain.

7.
Depending on your server configuration design, select the location where the Active Directory databases will be located.

Note

When you're configuring Active Directory database locations, make sure that your server hardware configuration plan takes recoverability and performance into account.

For best performance, install the Active Directory databases on a separate hard disk than the server operating system and server page file. Use the Browse buttons to select the disks where you want to store the Active Directory databases.

For best recoverability, use disk fault tolerance such as RAID or disk mirroring for the Active Directory databases.

8.
Use the Browse button to select the location where the SYSVOL folder will be installed or use the default location, and click Next. The SYSVOL folder contains the new Active Directory domain's data files. This information is replicated to all domain controllers in the domain and can be installed only on an NTFS volume. Your server design should account for the placement of the domain controller's SYSVOL folder. When you configure Active Directory permissions, the forest functionality must be configured for compatibility with other Windows Server family operating systems.

9.
If the new domain installation will contain only Windows Server 2003 domain controllers, select permissions compatible with Windows 2000 or Windows Server 2003 operating systems. This option is applicable only when you're adding new domain controllers to your domain. This does not affect backward compatibility when migrating existing Windows NT4 domains to Active Directory. For this example, select Permissions Compatible Only with Windows 2000 or Windows Server 2003 Operating Systems and click Next to continue.

10.
Assign a username and password to the Directory Services Restore Mode account. The Directory Services Restore Mode password is used to recover a server in case of server failure. This password should be documented in a secure location in case a recovery of the server is required. When you're configuring the account name and password, keep in mind that each Windows Server 2003 server with Active Directory in the domain has its own unique Directory Services Restore Mode account. This account is not associated with the Domain Administrator account or any other Enterprise Administrator accounts in Active Directory. Enter the Directory Services Restore Password and click Next.

11.
Review the server configuration and click Finish. This step will complete the installation of Active Directory.

Restart the domain controller by selecting Restart Now. Log in after the server restarts and review the server's Event Viewer application and system logs to identify any errors or potential problems with your installation before continuing.

Install and configure any additional domain controllers as planned in your Active Directory design and configure security as well as create all organizational units before migrating Windows NT4 security principles to Active Directory.

Configuring Domain Trust Between Windows NT4 and Windows Server 2003

When you're migrating existing NT4 domains to a new Active Directory forest root or child domain, you must create trust relationships between the existing Windows NT4 domains. The existing Windows NT4 domains are called the source domains, and the newly created Windows Server 2003 Active Directory domains are target domains.

Begin by configuring a trust on the target domain. On the Windows Server 2003 domain controller, open the Administrator Tools and launch Active Directory Domains and Trust Manager. From the Action menu, open the property page for your Active Directory domain and select the Trust tab.

Windows Server 2003 and Active Directory trusts are created using the New Trust Wizard. Select New Trust to start the wizard, which will guide you through the creation of a domain trust. Click Next at the Welcome screen.

On the Trust Name page, type in the name of the Windows NT4 source domain with which you would like to create a trust. You can use both the source domain's NetBIOS and fully qualified DNS name in this configuration. This will allow Active Directory to establish connectivity with the source Windows NT4 domain. Click Next to continue.

Note

When you're configuring a domain trust, each domain must have the capability to resolve the domain name to a domain controller's TCP/IP address. Install the Windows Internet Naming Service (WINS) on the target domain controller and configure the TCP/IP properties on the target and source domain controllers to use the newly installed WINS service.

The Windows Server 2003 forest functionality must be in Native mode to establish trust between Active Directory and Windows NT4. If you are experiencing problems creating a trust, raise the forest functional levels using the property page of the Active Directory domain.

Select the type of trust you want to establish. On the Direction of Trust page, select Two-Way, which will allow connectivity and access to resources in both the target and source domains when migrating. Then click Next to continue.

To configure outgoing trust properties, select Domain-wide Authentication. This option will allow Windows NT4 security principles access to all resources within the Active Directory target domain. Windows Server 2003 will automatically authenticate existing NT4 security principles within the target domain. This will allow required Administrator accounts access to each domain and domain group membership when you are ready to install the Active Directory Migration Tool and migrate security principles. Click Next to continue.

The trust password is a password other than the domain administrator password. It is unique to the trust being created and will be used by both the source and target domains to authenticate the trust. The same trust password must be used on both the Windows NT4 target domain and Windows Server 2003 source domain trust configurations. Enter a password for this trust to use and click Next to continue.

Review your trust configuration, select Back to modify any setting you want to change, or click Next to finish creating the trust and view the configuration changes created by the New Trust Wizard. Click Next to continue.

A dialog box will appear asking for confirmation of the outgoing trust. You cannot confirm the domain trust until a successful trust has been created on the Windows NT4 source domain. Before continuing, create and establish a trust relationship on the Windows NT4 source domain's primary domain controller. At the Confirm Outgoing Trust page, select the No, Do Not Confirm the Outgoing Trust option and click Next to continue.

Choose the No, Do Not Confirm the Incoming Trust option on the Confirm Incoming Trust page. Click Next to complete the trust configuration. Next, review the trust configuration and click Finish to close the New Trust Wizard.

To successfully establish a trust on the Windows NT source domain, you must first configure the trusted domain. To add the target domain to the Windows NT4 trusted domains, open the User Manager for Domains on the Windows NT4 primary domain controller. Choose Policies, Trust Relationships to open the Windows NT4 Trust Relationship page.

Begin by selecting the Add button under Trusted Domains. Enter the name of the target domain and a password that will be used by both domains to authenticate the trust. As mentioned earlier, this password is unique to the trust configuration and should be different from the Domain Administrator account password. This password will be used only to authenticate the domain trust between the source and target domains.

After the trusted domain is established successfully, select Add under the Trusting Domain section of the page. Enter the name of the target domain and the password used to establish the trust. This will add the target domain to the Windows NT4 trusting domains and complete the configuration of the Windows NT4 trust. Click Close to close the Trust Relationships page.

After you successfully create the trust between the source and target domain, the New Trust Wizard can confirm the trust for both outgoing and incoming trusts. If you choose to validate the trust, use the Administrator account name and password of the source domain to test access for both incoming and outgoing connectivity of the domain trust. Click OK to close the open dialog box.

Migrating Account and Resource Domains to Windows Server 2003 and Active Directory

Using the option to migrate account and resource domains to Windows Server 2003 and Active Directory allows you to restructure existing Windows NT4 accounts and resources into newly created Windows Server 2003 Active Directory domains and organizational units.

Before beginning your migration to Windows Server 2003, review the Active Directory design decisions you made in Chapter 5 of this book. The design decisions such as organizational unit configuration and group definition make up the framework of the Active Directory structure. When you use the Active Directory Users and Computers MMC snap-in, the creation of OUs and groups should match the OU and Group design.

Migrating account domains and resource domains to Active Directory organizational units allows for enhanced security and ease of delegation within the Active Directory domain tree. After you finish configuring the Active Directory domain's organizational unit structure, you can begin migrating domain resources and security principles using the Active Directory Migration Tool, as shown in Figure 16.4. Review the "Using Microsoft Active Directory Migration Tool" section at the end of this chapter to step through the migration process.

Figure 16.4. Migrating to organizational units and child domains.

Implication of Migrating Security Principles

When security principles are created in a Windows NT4 domain, each individual object is assigned a unique security identifier (SID). Each security principle's SID is unique and contains information about that specific security principle's group and domain membership.

When these types of security principles are migrated to Windows Server 2003 and Active Directory, each security principle is assigned a new SID with information about its new domain and group membership. Because the new SID does not contain information about the security principle's previous domain membership, when users or groups access domain resources on the old Windows NT4 domain, such as files, they may find that they no longer have permission to specific resources.

To avoid these problems during and after your migration, use the Microsoft Active Directory Migration Tool to migrate the security principles' SID history. The SID history is a record of each specific security principle's previous Windows NT4 group and domain membership. The Active Directory Migration Tool can migrate the security principles' SID history for each object maintaining previous information and preventing permissions problems later in the migration.


Consolidating Windows NT4 Domains

In the past, when organizations acquired new companies, additional Windows NT4 domains were often added into their existing domain environment using Windows NT4 trust relationships. With these additions, the manageability of domains, domain trusts, and domain resources became difficult. Consolidating Windows NT4 domains into Windows Server 2003 and Active Directory allows organizations to maintain the original Windows NT4 domain structure or domain name. Additional domain structures can be consolidated into organizational units within the Active Directory forest as well. By upgrading domains and migrating additional domains into organizational units, administrators can further enhance security and manageability of Active Directory objects.

Note

Before you begin the domain consolidation process, make sure that all preparation tasks have been completed and your migration script is prepared and tested in a separate lab environment. Using this migration path will copy or clone all Windows NT security principles rather than modify them on the original Windows NT domains.

If you incorporate both an inplace upgrade along with the Active Directory Migration Tool, you can consolidate Windows NT4 domains into Active Directory domains and organizational units within each domain, as shown in Figure 16.5.

Figure 16.5. Consolidating domains into organizational units.

This option is designed to allow administrators to downsize any existing Windows NT4 model while increasing administrative functionality by using Active Directory organizational units to maintain old Window NT4 domains.

Upgrading an Existing NT4 Domain to a New Active Directory Forest Root Domain

You begin the domain consolidation process by selecting and upgrading an existing Windows NT4 domain or multiple domains to an Active Directory forest. Depending on your Active Directory design, this inplace upgrade can become the first domain in a new forest or a child domain of a new Active Directory forest root.

Whether you are upgrading a single domain or multiple domains, begin by performing an inplace upgrade of the Windows NT4 domain that will become the Active Directory forest root or a child domain of a new Active Directory forest root. Use the same procedures outlined in the "Performing an Inplace Upgrade" section earlier in this chapter.

Restructuring Existing Account and Resource Domains to Active Directory

The primary purpose for using the domain consolidation migration process is to enable administrators to consolidate Windows NT4 domains into new Active Directory domains and organizational units. When the Active Directory forest is in place, any additional Windows NT4 domains can then be migrated to organizational units within the new Active Directory forest.

Because the original domains have been upgraded, all trust relationships are maintained, and the new Active Directory forest is ready to migrate security principles from Windows NT4. Before you begin, complete any restructuring tasks needed on the upgraded domain structure and create any additional organizational units needed. Use the procedures defined in the "Using Microsoft Active Directory Migration Tool" section to consolidate Windows NT domains to Active Directory organizational units and child domains.


Using Microsoft Active Directory Migration Tool

The Active Directory Migration Tool, also known as ADMT, is a powerful utility provided with the Windows Server 2003 operating system. ADMT allows Windows NT4 domain security principles to be migrated directly to Windows Server 2003 and Active Directory. The Active Directory Migration Tool provides wizards that enable you to perform the following:

  • Test migrations to identify any potential issues before you perform any actual migrations

  • User migrations to migrate user accounts from domain to domain, or forest to forest

  • User profile migrations to migrate user profile information from source to destination user account

  • Group migrations to move group and group membership information between source and destination domains or forests

  • Computer account migrations to migrate computer accounts from one domain or forest to another

  • Service account migrations to migrate the service account from one system or domain to another

  • Domain trust migrations to relink domain trusts from one domain to another domain

  • Password migrations to move user passwords when a user account is migrated from one domain or forest to another

After security principles are migrated to Active Directory, the ADMT also allows administrators to perform intraforest migrations of Active Directory objects. Objects can then also be moved between Active Directory domains and child domains as well as organizational units within the new Active Directory forest.

Installing the Active Directory Migration Tool

Before you install the Active Directory Migration Tool, make sure that your network meets the following requirements:

  • Domain trusts are established between Windows NT and Active Directory domains.

  • The Active Directory Administrator account is a member of the Windows NT4 Domain Administrators group.

  • The Windows NT4 Administrator account is a member of the Windows Server 2003 Local Administrators group.

The Active Directory Migration Tool can be installed from the Windows Server 2003 operating system CD-ROM. Use Windows Explorer to view the contents under the I386 directory of your installation CD. Launch the ADMIGRATION.MSI package file located in the ADMT folder to run the Active Directory Migration Tool Installation Wizard.

At the Welcome screen, click Next to continue. Accept the End User License Agreement and click Next to begin the installation of the ADMT. Click Next to accept the default folder for installation. Complete the installation and click Finish to close the Active Directory Migration Tool Installation Wizard.

Note

It is a good practice to install the ADMT utility on a domain controller located in the target domain. During the installation of the ADMT, the Setup Wizard will also make additional configuration changes within each domain being migrated. Review the README.DOC file in the ADMT installation directory to identify additional ADMT installation tasks and prerequisites.

Migrating Domain Accounts and Groups to Active Directory

Using the Active Directory Migration Tool to migrate accounts and groups to Active Directory requires that you configure several options. The following steps will guide you through the migration process for cloning user accounts, service accounts, and Windows NT domain groups to Active Directory:

1.
To run the Active Directory Migration Tool, launch ADMT from the program group on the Active Directory domain controller. Choose Start, Administration Tools, Active Directory Migration Tool.

2.
Choose Action, ADMT User Account Migration Wizard and then click Next. The Migration Wizard will then begin to migrate users to Active Directory.

Note

It is always a good practice to test any migration before actually migrating a user account. Do not continue with the migration unless you are ready to begin migrating users to Active Directory.

3.
To begin migrating user accounts, select the Migrate Now option and click Next to begin migrating users to Active Directory.

4.
The Domain Selection page allows you to choose the source and target domains for your migration. Use the drop-down box to select the domains for this migration and then click Next to continue.

Note

If the target domain is not in Native mode, an error dialog box will pop up. This error must be corrected immediately; otherwise, the process will not be able to proceed.

5.
Select the user account or accounts for this migration by clicking the Add button. You can enter the names manually or select multiple users at one time by clicking the Advanced button and searching for users. When you're done selecting, click OK to close the Advanced Select Users screen and return to the User Selection page. Ensure that all users have been selected and then click Next to continue.

6.
Use the Organizational Unit Selection page to identify the target OU location where the user accounts will be cloned. This is the organizational unit that will house the user's account for this migration. Select the Browse button to navigate to the proper OU in the target domain. Click OK to close the Browse the Container screen and return to the Organizational Unit Selection page. Click Next to continue.

7.
To enable the migration of user passwords from the NT Source domain, you must install an ADMT password export server. If no password server exists, review the ADMT help for information on password migrations for more info.

8.
Select the specific account options for each account being migrated. You can choose from the following Target Account State options:

  • Enable Target Account This option enables users to immediately log on to the new Active Directory domain after their accounts have been migrated.

  • Disable Target Account This option disables the newly created account, not allowing any users to log in to the new Active Directory domain.

  • Target Same As Source This option compares and sets the newly created account to whatever state the account is in the target domain.

  • Enable Target Account This option activates the target account after the migration process is completed.

  • Disable Source Account This option allows administrators to disable the migrated account in the source domain after the account is cloned to Active Directory. This option can also be used to set limits to the number of days an account should stay active after the migration is complete.

  • Days Until Server Accounts Expires Use this option to prevent users from accessing the source domain after an account has been migrated. This will prevent any account access in the source domain once the allotted time has expired.

9.
Select the Disable Source Account option for this migration. This will disable all accounts being migrated in the source domain.

10.
To migrate SID history for the account being migrated, select Migrate Users SID to Target Domain. This will migrate the account's SID attributes from the source domain to the new target domain.

The ADMT requires configuration changes be made before it can continue migrating users. When the error dialog boxes appear, follow the installation instructions in the following sections to perform additional tasks on both the source and target domains.

Migrating SID history requires auditing be enabled on the source and target domains. If auditing has not been enabled, an error dialog box will appear for both the source and target domain auditing.

11.
Select Yes to enable auditing on the source and target domain and continue with the migration.

12.
If you want to migrate a user's SID history, the local group NTDomain must exist on the source domain. If the group has not already been created, you can make the Migration Wizard create the group by selecting Yes when the error dialog box appears.

13.
Select Yes to add the TcpipClientSupport Registry key to the source domain.

14.
After the Registry change is made, select Yes to reboot the source domain PDC. Click OK and wait for the Windows NT domain PDC to finish rebooting before continuing.

15.
If your migration requires you to maintain a user's SID history, you must enter the username and password of an account with Administrator rights in the source domain. Enter the name of the source domain administrator and administrator password as well as the name of the Windows NT source domain.

By using the User Options described in Table 16.1, you can select and customize the user attributes of each user account being migrated.

Table 16.1. User Options

ADMT Options

Description

Translate Roaming Profiles

Use the Translate Roaming Profiles option if the user accounts you have selected are configured with roaming profiles on the Windows NT4 source domain. The Translate Roaming Profiles option copies the selected user account's roaming profile to the target domain and associates the profile with the account created in the target domain.

Update User Rights

If your migration plan requires that different systems coexist and Active Directory users will continue to access resources within the original source domain, select the Update User Rights option. This option copies the original user's rights to the new account created in the target domain, thus maintaining access to resources within the Windows NT4 source domain.

Migrate Associated User Groups

An effective way to migrate users is to use groups. When you select the Migrate Associated User Groups option, ADMT creates the groups associated with the user accounts you are migrating and maintains group membership in the target domain.

Update Previously Migrated Objects

Often when you're migrating in increments, user groups are already migrated when you continue to migrate accounts. The Update Previously Migrated Objects option associates group membership even if the group was previously migrated. Note that you can choose the Update Previously Migrated Objects option only if the Migrate Associated User Groups option is selected. Use the Select How All Migrated Accounts Should Be Named option to customize the way users will be viewed after they are migrated to the target domain and Active Directory.

Do Not Rename Accounts

The Active Directory Migration Tool migrates user accounts using the same information as in the source domain. You can use the Do Not Rename Accounts option if there are no user objects with names that conflict with accounts being migrated. Do not use this option as a method to resolve account name conflicts during the migration. Suffix and prefix options can be used to identify accounts after migrating to the target domain. An additional option will allow name conflict resolution later in the migration. The Naming Conflicts page in ADMT displays a list of names that have conflicts between user accounts being migrated and existing user accounts in the target domain.

Rename with Prefix

Use the Rename with Prefix option to add a prefix to user-names being migrated. This option can be used to prevent duplicate name conflicts in the target domain and is often used when consolidating account domains into an existing Active Directory forest.

Rename with Suffix

The Rename with Suffix option adds the specified suffix to the user accounts being migrated. As with the Rename with Prefix option, you should use this option if your target domain contains accounts that could conflict with account names being migrated.

Note

Review the ADMT options to determine which options will be used for your migration. It is best practice to test the migration options before actually performing a migration.

16.
After reviewing the selections on the User Options page, make sure that the proper selections have been made and click Next to continue.

17.
On the Naming Conflicts page, select the action that ADMT should perform to resolve naming conflicts if accounts in the target domain exist with the same name as accounts being migrated from the source domain.

Resolving Naming Conflicts

When duplicate account names exist in both the target and source domain, using the Ignore Conflicting Accounts and Don't Migrate option leaves accounts in the target domain intact and does not migrate any accounts that conflict from the source domain to the target domain.

When you replace existing accounts, each conflicting user account in the target domain will inherit the permissions and properties of the conflicting account name in the source domain. Essentially, any duplicate name being migrated will replace the duplicate account within Active Directory and also apply any SID changes configured for the source account domain.

If you choose to replace an existing account, you must decide whether the user rights to the conflicting account should be maintained. This option will ensure that conflicting accounts in the target domain do not have more user rights than the account being migrated from the target domain.

If you select Replace Conflicting Accounts, the Remove Existing Members of Groups Being Replaced option is enabled. This option compares and ensures members of migrated groups in the target domain are identical to group memberships in the source domain.

Similar to the Prefix and Suffix options on the User Options page, you should use the Rename Conflicting Accounts option to add a prefix or suffix to user accounts being migrated that conflict with accounts in the target domain. Adding a prefix to accounts that conflict can help you easily identify accounts that need correction after they are migrated.

Ensure that all options have been selected and are correct before continuing. Then click Next to continue. Use the scrollbar to review the Migration Wizard's task descriptions. Ensure that all options you have selected are identified before continuing. Click Finish to close the wizard and complete the migration. On the Migration Progress screen, you can view the results of your user migration. Select the View Log button to review the migration log and identify any errors. When you're done reviewing, click Close to shut the User Account Migration Wizard.

Migrating NT4 Groups into Active Directory

This section describes the options for merging or migrating Windows NT4 groups to Windows Server 2003 and Active Directory. This section also addresses options available when you're using ADMT to perform these task as well as the steps involved.

It is always a good practice to test any migration and review the results before actually migrating NT domain security principles. You can test the migration by selecting the Test the Migration Setting and Migrate Later from the Test or Make Changes page of the Group Migration Wizard. Launch the Group Account Migration Wizard from the Action menu to first test a group migration and then later perform the actual migration.

To perform an actual group account migration, do the following:

1.
From the Action menu, launch the Group Account Migration Wizard to begin the actual migration of Windows NT4 Groups.

2.
At the Welcome screen, click Next to continue. Select the Migrate Now option from the Test or Make Changes page and then click Next.

3.
On the Domain Selection page, use the drop-down box to select the source and target domains for this migration. Then click Next to continue.

4.
On the Group Selection page, enter the name or names of the groups in the source domain you want to migrate. Select the Add button to enter the group name and select Check Name to validate the group name. Click OK to add the group to the Group Selection page and then click Next to continue migrating.

5.
On the Organizational Unit Selection page, select the target OU to indicate where the group will be migrated. Use the Browse button to view the Active Directory tree and select the target domain and organizational unit that will host the migrated group. Click OK to finish the selection and then click Next to continue.

6.
When you're migrating Windows NT4 groups, options such as user rights and group membership can also be migrated. Review the group migration options on the Group Options page, as described in the following list, and choose the selections that best fit your migration needs:

  • Update User Right The Update User Right option copies a group's NT4 permission in the source domain to the new group in the target domain.

  • Copy Group Membership The Copy Group Membership option is essentially for organizations wanting to migrate to Windows Server 2003 one group at a time. This option allows ADMT to copy Windows NT source domain accounts that are members of the groups being migrated. Each account is then copied to the target domain and associated with the proper group membership. If you select Update Previously Migrated Objects, any existing accounts in the target domain will be updated with the proper group membership if those accounts existed within the target domain.

  • Fix Group Membership If members of the group being migrated exist in the source domain, the Fix Group Membership option will add migrated user accounts to the migrated group if they were members of the group in the target domain.

  • Migrate Group SID to Target Domain If your migration strategy requires access to resources in the target domain, select Migrate Group SID to Target Domain. This option adds the SID history to cloned users' accounts and groups after they are migrated to the target domain.

  • Do Not Rename Accounts The ADMT also migrates groups using the same group name as in the source domain. Use the Do Not Rename Accounts option if there are groups with the same group name that can conflict with the Windows NT4 groups being migrated. Groups are consolidated within the target domain if this option is selected.

  • Rename with Prefix Use the Rename with Prefix option to add a prefix to group names being migrated. This option can be used to avoid group name conflicts in the target domain.

  • Rename with Suffix The Rename with Suffix option adds the specified suffix to the group name being migrated. As with the Rename with Prefix option, you should use this option if your target domain contains group names that could conflict with the groups being migrated.

7.
Review the migration selection and ensure that the proper options have been checked. Click Next to continue migrating groups.

8.
If ADMT has not already been authenticated to the source domain, a login dialog box will appear.

9.
Use the Naming Conflicts page to configure actions ADMT should take to resolve conflicts with group names and group memberships. Review each of the following options before continuing the migration:

  • Ignore Conflicting Accounts and Don't Migrate The Ignore Conflicting Accounts and Don't Migrate option leaves accounts in the target domain unchanged and does not migrate any groups already existing in the target domain.

  • Replace Conflicting Accounts When you choose the Replace Conflicting Accounts option, each conflicting account in the target domain inherits the permissions and properties of the account being migrated from the source domain.

  • Remove Existing User Rights If you choose to replace an existing account, you must decide whether the user rights to conflicting accounts should be maintained. Selecting the Remove Existing User Rights option ensures that conflicting accounts in the target domain do not have more user rights than the account being migrated for the target domain.

  • Remove Existing Members of Groups Being Replaced If the Remove Existing Members of Groups Being Replaced option is selected, ADMT will compare and ensure that members of migrated groups in the target domain are identical to group memberships in the source domain. To enable this option, select Replace Conflicting Accounts.

  • Move Replaced Accounts to Specified Target Organizational Unit This option removes any existing account in the target domain that is the same as accounts being migrated.

  • Rename Conflicting Accounts by Adding the Following Similar to the prefix and suffix options, the Rename Conflicting Accounts options can be used to avoid conflicts with existing accounts in the target domain. You can add a prefix or suffix that the ADMT should use if conflicting group names are encountered. Then click Next to continue after options are set properly.

10.
Use the scrollbar to review the Migration Wizard task description. Ensure that all options you have selected are identified in the summary before clicking Finish to continue. The Migration Progress screen allows you to view the results of your group migration. You also can select the View Log button to review the migration log details for any errors. Exit the migration log and click Close to complete the Group Account Migration Wizard.

Migrating Computer Accounts to Active Directory

As well as migrating users and groups, you must migrate computer accounts for users to be able to authenticate to the new Windows Server 2003 Active Directory domain. Use the following steps to guide you through the Computer Migration Wizard for both testing and migrating computer accounts.

Note

When you're migrating computer accounts using the ADMT Computer Migration Wizard, ADMT will install an agent on each system in the source domain being migrated. This agent will restart the system after the Migration Wizard joins the computer account to the target domain.

1.
From the ADMT MMC, choose Action, Computer Migration Wizard to begin migrating computer accounts to Active Directory. Click Next to proceed past the Computer Migration Wizard Welcome screen.

2.
Select the Migrate Now option from the Test or Make Changes page and click Next to continue.

3.
On the Domain Selection page, use the drop-down box to select the source domain from which the computer accounts reside and the target domain where the computer accounts will be migrated to. After you select the domains, click Next to continue.

4.
On the Computer Selection page, enter the name or names of the computer accounts in the source domain you want to migrate. Click the Add button to enter and check the computer account names that will be migrated. Click Next to continue.

5.
On the Organizational Unit Selection page, select the target OU where the computer accounts will be migrated to. Use the Browse button to view the Active Directory tree and select the target domain and organizational unit that will host the computer accounts being migrated; then click Next to continue.

6.
Define the computer security associations to migrate on the Translate Objects page from the following list of options:

  • Files and Folders This option allows all local computer files and folder permissions to be translated to Active Directory after the computer accounts are migrated. If the computer being migrated hosts files accessed through Windows NT permissions, select this option to translate local security on files to Active Directory.

  • Local Groups ADMT can also migrate local security, and the computer local groups are migrated to Active Directory when you select this option.

  • Printers If there are shared printers located on the computer being migrated, this option translates all local rights to printer resources from Local Windows permission to Active Directory.

  • Registry This option migrates all security information from the local computer Registry being migrated.

  • Shares When you select this option, any configured shares and share permissions will be migrated to Active Directory.

  • User Profiles This option migrates all user profile security located on the local computer.

  • User Rights This option translates local user rights to Active Directory.

Note

Depending on the security options you select, you may see additional pages. Select the proper options and review each selection before continuing.

7.
For this computer migration, select the User Profiles option to translate the security of user profiles on the computers being migrated. Then click Next to continue.

8.
In the Security Translation Options window, define the security option for migrating computer accounts from one of the following options:

  • Replace This option replaces all account SID information with new SID information from the target domain. This option gives the computer account in the target domain the same permissions and access to resources as the account was configured in the source domain.

  • Add This option combines the SID information of the computer account in the target domain to all ACLs in the source domain, thus allowing the computer account to access resources within the Windows NT domain.

  • Remove This option removes all SID information for the computer account from all ACLs in the source domain. This option does not allow the computer account to access resources in the Windows NT4 domain after it has been migrated.

9.
Validate the action or actions you have selected on the Security Translation page and select Next to continue the computer migration process.

10.
On the Computer Options page, configure the restart time of the computer being migrated as well as the prefix and suffix to add to the computer name being migrated. Click Next to continue migrating computer accounts.

11.
Use the Naming Conflicts page to configure actions ADMT should take to resolve conflicts with computer accounts and membership in the target domain. Review each of the following options before continuing the migration:

  • Ignore Conflicting Accounts and Don't Migrate The Ignore Conflicting Accounts and Don't Migrate option leaves computer accounts in the target domain unchanged and does not migrate any computer accounts that already exist in the target domain.

  • Replace Conflicting Accounts When you replace existing computer accounts, each conflicting account in the target domain will inherit the permissions and properties of the computer account being migrated from the source domain.

  • Remove Existing User Rights If you choose to replace an existing account, you must decide whether the user rights to conflicting accounts should be maintained. Selecting this option ensures that conflicting computer accounts in the target domain do not have more user rights than the computer accounts being migrated from the target domain.

  • Remove Existing Members of Groups Being Replaced By selecting this option, you can compare and ensure members of migrated groups in the target domain are identical to computer group memberships in the source domain.

  • Move Replaced Accounts to Specified Target Organizational Units If you select this option, any existing computer accounts will be replaced by accounts being migrated to the target OU.

The Rename with Prefix and Rename with Suffix options can be used to avoid conflicts with existing computer accounts in the target domain. You can add the prefix or suffix that ADMT should use if conflicting computer names are encountered.

Review the Task Descriptions page to determine whether all your migration options are accurate. Use the scrollbar to see each option configured. Changes can be made before you continue by selecting the Back button. To use the settings shown and continue with the selected tasks, click Finish.

Migrating Service Accounts to Active Directory

When you need to perform an inplace upgrade as well as support applications that require service accounts such as Microsoft Exchange and other third-party products, the ADMT Service Account Migration Wizard can assist you in moving this account information to Active Directory.

1. | From the ADMT MMC, launch the Service Account Migration Wizard by choosing Action, Service Account Migration Wizard.
2. | Select the source domain from which the service accounts reside and the target domain where the service accounts will be migrated. Click Next when you are ready to continue.
3. | The Update Service Account Information page will gather service account information for the selected source's domain. If this is the first time you're using the Service Account Migration Wizard, select Yes, Update the Information. The No, Use Previously Collected Information option is not available if the wizard has not been run previously. This option allows you to migrate service accounts without collecting service account information each time the wizard is run.
4. | On the Service Account Selection page, enter the computer to host the service accounts you want to migrate. Click the Add button to enter and check the computer account names that host the service accounts being migrated. Click OK to continue.
5. | The Active Directory Migration Tool Monitor will appear. Review the status as the ADMT installs the agent on the computers selected.
6. | On the Service Account Information page, review the service accounts being migrated. Use the Skip/Include button to select or deselect accounts for this migration. You can choose the Update CSM Now option to update the service control entry. After you select the proper accounts, click Next to continue.
7. | The Service Account Migration Wizard summary will verify the tasks and results of the migration. Use the scrollbar to review the tasks of the service account migration. Click Finish to close the Service Account Migration Wizard.

The Active Directory Migration Tool can be used to migrate additional Windows NT4 domain resources to Active Directory. Always review the results of each migration and test permissions and functionality before continuing with any of these types of migrations.


Summary

When migrating directly to Windows Server 2003 from Windows NT4, you must consider many factors while preparing and performing the migration. This chapter covered the three main migration methods as well as the tools available from Microsoft to assist with the migrations.

The inplace upgrade is by far the easiest method for migration and retains security principles and configuration settings that minimize interruption of the network. However, for some organizations that want to start with a completely clean structure, the second option of migrating Windows NT4 objects such as user accounts, computer accounts, and the like to a new Active Directory forest allows organizations to start completely from scratch. The third option is to consolidate multiple existing Windows NT4 domains into a single Active Directory domain configuration. This consolidation method is frequently used by organizations that want to minimize the number of domains they have. All three options serve their purpose for various migration needs. Organizations that want to migrate will find one of these options will best fit their needs.


Best Practices

  • Before migrating servers to Windows Server 2003, determine whether your Windows NT4 server hardware and Windows NT4 server-based applications are compatible with the Windows Server 2003 family operating system.

  • Use the Microsoft Compatibility Check Tool available on the Windows Server 2003 installation CD-ROM to test application compatibility.

  • Before you begin an inplace upgrade of a domain, it is a good practice to force synchronize the primary domain controller and backup domain controllers.

  • Seriously consider performing an inplace upgrade from Windows NT4 to Windows 2003 instead of building a brand-new forest and moving objects to minimize the time, effort, cost, and user interruption involved in a clean forest migration process.

  • Review the server event and system logs upon completing any upgrade.

  • Review the Active Directory Users and Computers snap-in to ensure that all security principles have been migrated successfully to Window Server 2003 and Active Directory.

  • Before migrating BDCs, review the backup domain controller and member server's application and system logs to identify issues that can affect the progress of your migration.

  • When configuring the Active Directory database locations, ensure that your server hardware configuration plan takes recoverability and performance into account.

  • For best performance, install the Active Directory databases on a separate hard disk than the server operating system and server page file.

  • For best recoverability, use disk fault tolerance such as RAID or disk mirroring for the Active Directory databases.

  • If you are experiencing problems creating a trust, raise the forest functional levels using the Properties page of the Active Directory domain.

  • Install the ADMT utility on a domain controller located in the target domain when possible.

  • Test any (ADMT) migration before performing an actual migration of user accounts.


Chapter 17. Migrating from Windows 2000 to Windows Server 2003

In This Chapter

  • Windows Server 2003 Migration Overview

  • Beginning the Migration Process

  • Upgrading a Single Member Server

  • Upgrading a Windows 2000 Active Directory Forest

  • Upgrading Separate AD Forests to a Single Forest Using Mixed-Mode Domain Redirect

  • Consolidating and Migrating Domains Using the Active Directory Migration Tool v2.0

  • Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT v2.0


Windows Server 2003 Migration Overview

In many ways, a migration from Windows 2000 to Windows Server 2003 is more of a service pack upgrade than a major migration scenario. The differences between the operating systems are more evolutionary than revolutionary, and there subsequently are fewer design considerations than in upgrades from the NT 4.0 operating system.

That said, several immediate improvements to the operating system can be realized through migration to Windows Server 2003, whether by migrating all servers immediately or by using a slow, phased approach. Improvements to Active Directory (AD), such as the ability to rename domains and greater scalability, provide incentive for Windows 2000 Active Directory environments to begin migration. Standalone server improvements such as Terminal Services, File and Print Server improvements, Automated Server Recovery, and many more also serve to encourage migrations.

This chapter focuses on the planning, strategy, and logistics of migration from Windows 2000 to Windows Server 2003. In addition, specialized procedures such as using Mixed-Mode Domain Redirect and migrating using the Active Directory Migration Tool (ADMT) are described, and step-by-step instructions complement these processes.


Beginning the Migration Process

Any migration procedure should define the reasons for migration, steps involved, fallback precautions, and other important factors that can influence the migration process. After finalizing these items, the migration can begin.

Identifying Migration Objectives

Two underlying philosophies influence technology upgrades, each philosophy working against the other. The first is the expression "If it ain't broke, don't fix it." Obviously, if an organization has a functional, easy-to-use, and well-designed Windows 2000 infrastructure, popping in that Windows Server 2003 CD and upgrading may not be so appealing. The second philosophy is something along the lines of "Those who fail to upgrade their technologies perish."

Choosing between these two philosophies effectively depends on the factors that drive an organization to upgrade. If the organization has critical business needs that can be satisfied by an upgrade, such an upgrade may be in the works. If, however, no critical need exists, it may be wise to wait until the next iteration of Windows or a future service pack for Windows Server 2003.

Establishing Migration Project Phases

After the decision is made to upgrade, a detailed plan of the resources, timeline, scope, and objectives of the project should be outlined. Part of any migration plan requires establishing either an ad hoc project plan or a professionally drawn-up project plan. The migration plan assists the project managers of the migration project accomplish the planned objectives in a timely manner with the correct application of resources.

The following is a condensed description of the standard phases for a migration project:

  • Discovery The first portion of a design project should be a discovery, or fact-finding, portion. This section focuses on the analysis of the current environment and documentation of the analysis results. Current network diagrams, server locations, WAN throughputs, server application dependencies, and all other networking components should be detailed as part of the Discovery phase.

  • Design The Design portion of a project is straightforward. All key components of the actual migration plan should be documented, and key data from the Discovery phase should be used to draw up Design and Migration documents. The project plan itself would normally be drafted during this phase. Because Windows Server 2003 is not dramatically different from Windows 2000, significant re-engineering of an existing Active Directory environment is not necessary. However, other issues such as server placement, new feature utilization, and changes in AD replication models should be outlined.

  • Prototype The Prototype phase of a project involves the essential lab work to test the design assumptions made during the Design phase. The ideal prototype would involve a mock production environment that is migrated from Windows 2000 to Windows Server 2003. For Active Directory, this means creating a production domain controller (DC) and then isolating it in the lab and promoting it to the Operation Master (OM) server in the lab. The Active Directory migration can then be performed without affecting the production environment. Step-by-step procedures for the migration can also be outlined and produced as deliverables for this phase.

  • Pilot The Pilot phase, or Proof-of-Concept phase, involves a production "test" of the migration steps, on a limited scale. For example, a noncritical server could be upgraded to Windows Server 2003 in advance of the migration of all other critical network servers. In a slow, phased migration, the Pilot phase would essentially spill into Implementation, as upgrades are performed slowly, one by one.

  • Implementation The Implementation portion of the project is the full-blown migration of network functionality or upgrades to the operating system. As previously mentioned, this process can be performed quickly or slowly over time, depending on an organization's needs. It is subsequently important to make the timeline decisions in the Design phase and incorporate them into the project plan.

  • Training and Support Learning the ins and outs of the new functionality that Windows Server 2003 can bring to an environment is essential in realizing the increased productivity and reduced administration that the OS can bring to the environment. Consequently, it is important to include a Training portion into a migration project so that the design objectives can be fully realized.

For more detailed information on the project plan phases of a Windows Server 2003 migration, refer to Chapter 2, "Planning, Prototyping, Migrating, and Deploying Windows Server 2003 Best Practices."

Comparing the Inplace Upgrade Versus New Hardware Migration Methods

Because the fundamental differences between Windows 2000 and Windows Server 2003 are not significant, the possibility of simply upgrading an existing Windows 2000 infrastructure is an option. Depending on the type of hardware currently in use in a Windows 2000 network, this type of migration strategy becomes an option. Often, however, it is more appealing to simply introduce newer systems into an existing environment and retire the current servers from production. This technique normally has less impact on current environments and can also support fallback more easily.

Determining which migration strategy to use depends on one major factor: the condition of the current hardware environment. If Windows 2000 is taxing the limitations of the hardware in use, it may be preferable to introduce new servers into an environment and simply retire the old Windows 2000 servers. If, however, the hardware in use for Windows 2000 is newer and more robust, and could conceivably last for another two to three years, it may be easier to simply perform inplace upgrades of the systems in an environment.

In most cases, organizations take a dual approach to migration. Older hardware is replaced by new hardware running Windows Server 2003. Newer Windows 2000 systems are instead upgraded in place to Windows Server 2003. Consequently, auditing all systems to be migrated and determining which ones will be upgraded and which ones retired are important steps in the migration process.

Identifying Migration Strategies: "Big Bang" Versus Slow Transition

As with most technology implementations, there are essentially two approaches in regard to deployment: a quick "Big Bang" approach or a phased, slower approach. The Big Bang option involves the entire Windows 2000 infrastructure being quickly replaced, often over the course of a weekend, with the new Windows Server 2003 environment; whereas the phased approach involves a slow, server-by-server replacement of Windows 2000.

Each approach has its particular advantages and disadvantages, and key factors to Windows Server 2003 should be taken into account before a decision is made. Few Windows Server 2003 components require a redesign of current Windows 2000 design elements. Because the arguments for the Big Bang approach largely revolve around not maintaining two conflicting systems for long periods of time, the similarities between Windows 2000 and Windows Server 2003 make many of these arguments moot. With this point in mind, it is more likely that most organizations will choose to ease into Windows Server 2003, opting instead for the phased migration approach to the upgrade. Because Windows Server 2003 readily fits into a Windows 2000 environment, and vice versa, this option is easily supported.

Migration Options

As previously mentioned, Windows Server 2003 and Windows 2000 "play" together very well. The added advantage to this fact is that there is greater flexibility for different migration options. Unlike migrations from NT 4.0 or non-Microsoft environments, the migration path between these two systems is not rigid, and different approaches can be used successfully to achieve the final objectives desired.


Upgrading a Single Member Server

The direct upgrade approach from Windows 2000 to Windows Server 2003 is the most straightforward approach to migration. An upgrade simply takes any and all settings on a single server and upgrades them to Windows Server 2003. If a Windows 2000 server handles WINS, DNS, and DHCP, the upgrade process will upgrade all WINS, DNS, and DHCP components, as well as the base operating system. This makes this type of migration very tempting, and it can be extremely effective, as long as all prerequisites described in the following sections are satisfied.

Often, upgrading a single server can be a project in itself. The standalone member servers in an environment are often the workhorses of the network, loaded with a myriad of different applications and critical tools. Performing an upgrade on these servers would be simple if they were used only for file or print duties and if their hardware systems were all up to date. Because this is not always the case, it is important to detail the specifics of each server that is marked for migration.

Verifying Hardware Compatibility

It is critical to test the hardware compatibility of any server that will be directly upgraded to Windows Server 2003. In the middle of the installation process is not the most ideal time to be notified of problems with compatibility between older system components and the drivers required for Windows Server 2003. Subsequently, the hardware in a server should be verified for Windows Server 2003 on the manufacturer's Web site or on Microsoft's Hardware Compatibility List (HCL), currently located at http://www.microsoft.com/whdc/hcl.

Microsoft suggests minimum hardware levels on which Windows Server 2003 will run, but it is highly recommended that you install the OS on systems of a much higher caliber because these recommendations do not take into account any application loads, domain controller duties, and so on. The following is a list of Microsoft's recommended hardware levels for Windows Server 2003:

  • Intel Pentium III 550MHz CPU or equivalent

  • 256MB RAM

  • 1.5GB free disk space

That said, it cannot be stressed enough that it is almost always recommended that you exceed these levels to provide for a robust computing environment.

Note

One of the most important features that mission-critical servers can have is redundancy. Putting the operating system on a mirrored array of disks, for example, is a simple yet effective way of increasing redundancy in an environment.

Verifying Application Readiness

Nothing ruins a migration process like discovering a mission-critical application will not work in the new environment. Subsequently, it is very important to list all applications on a server that will be required in the new environment. Applications that will not be used or whose functionality is replaced in Windows Server 2003 can be retired and removed from consideration. Likewise, applications that have been verified for Windows Server 2003 can be designated as safe for upgrade. For any other applications that may not be compatible but are necessary, you either need to delegate them to another Windows 2000 server or delay the upgrade of that specific server.

In addition to the applications, the version of the operating system that will be upgraded is an important consideration in the process. A Windows 2000 server install can be upgraded to either Windows Server 2003 Standard Server or Windows Server 2003 Enterprise Server. A Windows 2000 Advanced Server install can be upgraded only to Windows Server 2003 Enterprise Server, however. Finally, only Windows 2000 Datacenter Server edition can be upgraded to Windows Server 2003 Datacenter Server.

Backing Up and Creating a Recovery Process

It is critical that a migration does not cause more harm than good to an environment. Subsequently, we cannot stress enough that a good backup system is essential for quick recovery in the event of upgrade failure. Often, especially with the inplace upgrade scenario, a full system backup is the only way to recover; consequently, it is very important to detail fallback steps in the event of problems.

Upgrading a Standalone Server

After all various considerations regarding applications and hardware compatibility have been thoroughly validated, a standalone server can be upgraded. Follow these steps to upgrade:

1.
Insert the Windows Server 2003 CD into the CD-ROM drive of the server to be upgraded.

2.
The Welcome page should appear automatically. If not, choose Start, Run and then type d:\Setup, where d: is the drive letter for the CD-ROM drive.

3.
Click Install Windows Server 2003 (Enterprise Edition).

4.
Select Upgrade from the drop-down box, as indicated in Figure 17.1, and click Next to continue.

Figure 17.1. Starting the Windows Server 2003 upgrade.

5.
Select I Accept This Agreement at the License screen and click Next to continue.

6.
The following screen prompts you to enter the 25-character product key. You can find this number on the CD case or in the license documentation from Microsoft. Enter the product key and click Next to continue.

7.
The next screen allows for the download of updated Windows Server 2003 files. They may be downloaded as part of the upgrade or installed later. For this example, select No, Skip This Step and Continue Installing Windows. Then click Next to continue.

8.
The next prompt is crucial. It indicates which system components are not compatible with Windows Server 2003. It also indicates, for example, that IIS will be disabled as part of the install, as you can see in Figure 17.2. IIS can be re-enabled in the new OS but is turned off for security reasons. Click Next after reviewing these factors.

Figure 17.2. Checking the System Compatibility report.

[View full size image]

9.
The system then copies files and reboots, continuing the upgrade process. After all files are copied, the system is then upgraded to a fully functional install of Windows Server 2003. If upgrading to Windows Server 2003 R2, setup will then invoke the R2 upgrade process by asking to insert the second CD containing R2 information. Once inserted, the final R2 upgrade process can take place.

Note

Many previously enabled components such as IIS are turned off by default in Windows Server 2003. Ensure that one of the post-upgrade tasks performed is an audit of all services so that those disabled components can be re-enabled.


Upgrading a Windows 2000 Active Directory Forest

In many cases, the Windows 2000 environment that will be migrated includes one or many Active Directory domains and forests. Because Active Directory is one of the most important portions of a Microsoft network, it is subsequently one of the most important areas to focus on in a migration process. In addition, many of the improvements made to Windows Server 2003 are directly related to Active Directory, making it even more appealing to migrate this portion of an environment.

The decision to upgrade Active Directory should focus on these key improvement areas. If one or more of the improvements to Active Directory justifies an upgrade, it should be considered. The following list details some of the many changes made to Active Directory in Windows Server 2003:

  • Domain rename capability Windows Server 2003 Active Directory supports the renaming of either the NetBIOS name or the LDAP/DNS name of an Active Directory domain. The Active Directory rename tool can be used for this purpose, but only in domains that have completely upgraded to Windows Server 2003 domain controllers.

  • Cross-forest transitive trusts Windows Server 2003 now supports the implementation of transitive trusts that can be established between separate Active Directory forests. Windows 2000 supported only explicit cross-forest trusts, and the trust structure did not allow for permissions to flow between separate domains in a forest. This limitation has been lifted in Windows Server 2003.

  • Universal group caching One of the main structural limitations of Active Directory was the need to establish very "chatty" global catalog servers in every site established in a replication topology, or run the risk of extremely slow client login times and directory queries. Windows Server 2003 enables remote domain controllers to cache universal group memberships for users so that each login request does not require the use of a local global catalog server.

  • Inter-site topology generator (ISTG) improvements The ISTG in Windows Server 2003 has been improved to support configurations with extremely large numbers of sites. In addition, the time required to determine site topology has been noticeably improved through the use of a more efficient ISTG algorithm.

  • Multivalued attribute replication improvements In Windows 2000, if a universal group changed its membership from 5,000 users to 5,001 users, the entire group membership had to be re-replicated across the entire forest. Windows Server 2003 addresses this problem and allows incremental membership changes to be replicated.

  • Lingering objects (zombies) detection Domain controllers that have been out of service for a longer period of time than the Time to Live (TTL) of a deleted object could theoretically "resurrect" those objects, forcing them to come back to life as zombies, or lingering objects. Windows Server 2003 properly identifies these zombies and prevents them from being replicated to other domain controllers.

  • AD-integrated DNS zones in application partition Replication of DNS zones has been improved in Windows Server 2003 by storing AD-integrated zones in the application partition of a forest, thus limiting their need to be replicated to all domain controllers and reducing network traffic.

Note

For more information on the improvements to Active Directory and the ways they can be used to determine whether your organization should upgrade, refer to Chapter 4, "Active Directory Primer," Chapter 5, "Designing a Windows Server 2003 Active Directory," Chapter 6, "Designing Organizational Unit and Group Structure," and Chapter 7, "Active Directory Infrastructure."

Migrating Domain Controllers

After the decision is made to migrate the Active Directory environment, it is considered wise to make a plan to upgrade all domain controllers in an environment to Windows Server 2003. Unlike with member servers, the full benefits of the Active Directory improvements in Windows Server 2003 are not fully realized until the entire environment is "Windows Server 2003 functional," and all DCs are upgraded. With this in mind, a mixed Windows 2000/Windows Server 2003 domain controller environment can be maintained. However, upgrading all domain controllers in an environment to Windows 2000 Service Pack 2 or higher is highly recommended because an issue with replication between domain controllers was first addressed by that service pack.

There are two approaches to migrating domain controllers, similar to the logic used in the "Upgrading a Standalone Server" section. The domain controllers can either be directly upgraded to Windows Server 2003 or replaced by newly introduced Windows Server 2003 domain controllers. The decision to upgrade an existing server largely depends on the hardware of the server in question. The rule of thumb is, if the hardware will support Windows Server 2003 now and for the next two to three years, a server can be directly upgraded. If this is not the case, using new hardware for the migration is preferable.

Note

A combined approach can be and is quite commonly used, as indicated in Figure 17.3, to support a scenario in which some hardware is current but other hardware is out-of-date and will be replaced. Either way, the decisions applied to a proper project plan can help to ensure the success of the migration.

Figure 17.3. Combined approach to the upgrade process.

Upgrading the AD Schema Using adprep

The introduction of Windows Server 2003 domain controllers into a Windows 2000 Active Directory requires that the core AD database component, the schema, be updated to support the increased functionality. In addition, several other security changes need to be made to prepare a forest for inclusion of Windows Server 2003. The Windows Server 2003 CD includes a command-line utility called adprep that will extend the schema to include the extensions required and modify security as needed. Adprep requires that both forestprep and domainprep be run before the first Windows Server 2003 domain controller can be added.

The Active Directory schema in Windows 2000 is composed of 1,006 attributes, by default, as shown in Figure 17.4. After running adprep forestprep, the schema will be extended to include additional attributes that support Windows Server 2003 functionality.

Figure 17.4. ADSI Edit before running forestprep.

[View full size image]

Note

Windows Server 2003 R2 contains additional schema updates, above and beyond the additions that the RTM version of Windows Server 2003 introduced. If ADPrep is run from a server running R2, the schema will be extended to include not only the 2003 enhancements but the R2 ones as well.

The Adprep utility must be run from the Windows Server 2003 CD or copied from its location in the \i386 folder. The adprep /forestprep operation can be run on the server that holds the Schema Master Operations Master (OM) role by following these steps:

1.
On the Schema Master domain controller, choose Start, Run. Then type cmd and press Enter to open a command prompt.

2.
Enter the Windows Server 2003 CD into the CD drive.

3.
Where D: is the drive letter for the CD drive, type in D:\i386\adprep/forestprep and press Enter.

4.
Upon verification that all domain controllers in the AD forest are at Windows 2000 Server Pack 2 or greater, type C at the prompt and press Enter.

5.
The forestprep procedure extends the Windows 2000 AD schema, as illustrated in Figure 17.5. After the schema is extended, it is replicated to all domain controllers in the forest. Finally, close the command-prompt window.

Figure 17.5. Running the adprep forestprep procedure.

[View full size image]

After this step is accomplished, the domainprep procedure must be run.

The adprep /domainprep operation must be run once in every domain in a forest. It must be physically invoked on the server that holds the Operations Master (OM) role. The steps for executing the domainprep procedure are as follows:

1. | On the Operations Master domain controller, open a command prompt (choose Start, Run, then type cmd, and press Enter).
2. | Enter the Windows Server 2003 CD into the CD drive.
3. | Where D:\is the CD drive, type D:\i386\adprep/ domainprep and press Enter.
4. | Type exit to close the command prompt window.

After the forestprep and domainprep operations are run, the Active Directory forest will be ready for the introduction or upgrade of domain controllers to Windows Server 2003. The schema is extended and includes support for application partitions and other enhancements. The process of upgrading the domain controllers to Windows Server 2003 can then commence.

Note

Any previous extensions made to a Windows 2000 schema, such as those made with Exchange 2000/2003, are not affected by the adprep procedure. This procedure simply adds additional attributes and does not change those that currently exist.

Upgrading Existing Domain Controllers

If the decision has been made to upgrade all or some existing hardware to Windows Server 2003, the process for accomplishing this is straightforward. However, as with the standalone server, you need to ensure that the hardware and any additional software components are compatible with Windows Server 2003. After establishing this, the actual migration can occur.

The procedure for upgrading a domain controller to Windows Server 2003 is nearly identical to the procedure outlined in the previous section "Upgrading a Single Member Server." Essentially, simply insert the CD and upgrade, and an hour or so later the machine will be updated and functioning as a Windows Server 2003 domain controller.

Replacing Existing Domain Controllers

If you need to migrate specific domain controller functionality to the new Active Directory environment but plan to use new hardware, you need to bring new domain controllers into the environment before retiring the old servers. The process for installing a new server is similar to the process in Windows 2000, and the DCPromo utility can be used to promote a server to domain controller status.

Windows Server 2003 supports an enhanced Configure Your Server Wizard, however, which allows an administrator to designate a server into multiple roles. This is the most thorough approach, and the following steps show how to accomplish this to establish a new domain controller in a Windows 2000 Active Directory domain:

1.
Open the Configure Your Server Wizard (Start, All Programs, Administrative Tools, Configure Your Server Wizard).

2.
Click Next at the Welcome screen, shown in Figure 17.6.

Figure 17.6. Configure Your Server Wizard.

[View full size image]

3.
Verify the preliminary steps and click Next.

4.
Select Domain Controller from the list and click Next.

5.
Check the settings at the Summary page and click Next.

6.
After the AD Installation Wizard is invoked, click Next to continue.

7.
At the Operating System Compatibility window, click Next to verify that old versions of Microsoft software such as Windows 95 will not be supported.

8.
Select Additional Domain Controller for an Existing Domain and click Next.

9.
Type the password of an Administrator account in the AD domain and click Next to continue.

10.
Type the domain name into the dialog box of the target AD domain and click Next to continue.

11.
Enter a location for the AD database and logs. (You can achieve the best performance if they are stored on separate volumes.) Click Next to continue.

12.
Enter a location for the SYSVOL folder. Click Next to continue.

13.
Enter a password for Directory Services Restore Mode, which can be used in the event of directory recovery. Click Next to continue.

14.
Verify the tasks indicated and click Next to continue. The server then contacts another DC in the domain and replicates domain information, as indicated in Figure 17.7.

Figure 17.7. Configuring AD.

15.
Click Finish when the process is complete.

16.
Click Restart Now when prompted to reboot the domain controller and establish it in its new role in AD.

Moving Operation Master Roles

Active Directory sports a multimaster replication model, in which any one server can take over directory functionality, and each domain controller contains a read/write copy of directory objects. There are, however, a few key exceptions to this, in which certain forest-wide functionality must be held by a single domain controller. These exceptions are known as Operation Master (OM) roles, also known as Flexible Single Master Operation (FSMO) roles. There are five OM roles, as follows:

  • Schema Master

  • Domain Naming Master

  • RID Master

  • PDC Emulator

  • Infrastructure Master

If the server or servers that hold the OM roles are not directly upgraded to Windows Server 2003 but will instead be retired, these OM roles will need to be moved to another server. The best tool for this type of move is the nTDsutil command-line utility. Follow these steps using nTDsutil to move all OM roles to a single Windows Server 2003 domain controller:

1.
Open a command prompt (choose Start, Run and then type cmd and press Enter).

2.
Type ntdsutil and press Enter.

3.
Type roles and press Enter.

4.
Type connections and press Enter.

5.
Type connect to server <Servername>, where <Servername> is the name of the target Windows Server 2003 domain controller that will hold the OM roles, and press Enter.

6.
Type quit and press Enter.

7.
Type transfer schema master, as shown in Figure 17.8, and press Enter.

Figure 17.8. Using the ntdsutil utility to transfer OM roles.

[View full size image]

8.
Click Yes at the prompt asking to confirm the OM change.

9.
Type transfer domain naming master and press Enter.

10.
Click Yes at the prompt asking to confirm the OM change.

11.
Type transfer pdc and press Enter.

12.
Click OK at the prompt asking to confirm the OM change.

13.
Type transfer rid master and press Enter.

14.
Click OK at the prompt asking to confirm the OM change.

15.
Type transfer infrastructure master and press Enter.

16.
Click OK at the prompt asking to confirm the OM change.

17.
Type exit to close the command-prompt window.

Retiring Existing Windows 2000 Domain Controllers

After the entire Windows 2000 domain controller infrastructure is replaced by Windows Server 2003 equivalents and the OM roles are migrated, the process of demoting and removing all down-level domain controllers can begin. The most straightforward and thorough way of removing a domain controller is by demoting them using the dcpromo utility, per the standard Windows 2000 demotion process. After you run the dcpromo command, the domain controller becomes a member server in the domain and can safely be disconnected from the network.

Retiring "Ghost" Windows 2000 Domain Controllers

As is often the case in Active Directory, domain controllers may have been removed from the forest without first being demoted. This may happen due to server failure or problems in the administrative process, but you must remove those servers from the directory before completing an upgrade to Windows Server 2003. Simply deleting the object from Active Directory Sites and Services does not work. Instead, you need to use a low-level directory tool, ADSI Edit, to remove these servers. The following steps outline how to use ADSI Edit to remove these "ghost" domain controllers:

1.
Install ADSI Edit from the Support Tools on the Windows Server 2003 CD and open it.

2.
Navigate to Configuration\CN=Configuration\CN=Sites\CN=<Sitename>\ CN=Servers\CN=<Servername>, where <Sitename> and <Servername> correspond to the location of the ghost domain controller.

3.
Right-click CN=NTDS Settings and click Delete, as shown in Figure 17.9.

Figure 17.9. Deleting ghost domain controllers.

[View full size image]

4.
At the prompt, click Yes to delete the object.

5.
Close ADSI Edit.

At this point, after the NTDS Settings are deleted, the server can be normally deleted from the Active Directory Sites and Services snap-in.

Upgrading Domain and Forest Functional Levels

Windows Server 2003 does not immediately begin functioning at a native level, even when all domain controllers have been migrated. In fact, a fresh installation of Windows Server 2003 supports domain controllers from Windows NT 4.0, Windows 2000, and Windows Server 2003. You first need to upgrade the functional level of the forest and the domain to Windows Server 2003 before you can realize the advantages of the upgrade.

Windows Server 2003 supports four functional levels. The following levels allow Active Directory to include down-level domain controllers during an upgrade process:

  • Windows 2000 Mixed Domain Functional Level When Windows Server 2003 is installed into a Windows 2000 Active Directory forest that is running in Mixed mode, it essentially means that Windows Server 2003 domain controllers can communicate with Windows NT and Windows 2000 domain controllers throughout the forest. This is the most limiting of the functional levels, however, because functionality such as universal groups, group nesting, and enhanced security is absent from the domain. This is typically a temporary level to run in because it is seen more as a path toward eventual upgrade.

  • Windows 2000 Native Functional Level Installed into a Windows 2000 Active Directory that is running in Windows 2000 Native mode, Windows Server 2003 runs itself at a Windows 2000 functional level. Only Windows 2000 and Windows Server 2003 domain controllers can exist in this environment.

  • Interim Level Windows Server 2003 Interim mode enables the Windows Server 2003 Active Directory to interoperate with a domain composed of Windows NT 4.0 domain controllers only. Although this is a confusing concept at first, the Windows Server 2003 Interim functional level does serve a purpose. In environments that seek to upgrade directly from NT 4.0 to Windows Server 2003 Active Directory, Interim mode allows Windows Server 2003 to manage large groups more efficiently than if an existing Windows 2000 Active Directory exists. After all NT domain controllers are removed or upgraded, the functional levels can be raised.

  • Windows Server 2003 Functional Level The most functional of all the various levels, Windows Server 2003 functionality is the eventual goal of all Windows Server 2003 Active Directory implementations.

After all domain controllers are upgraded or replaced with Windows Server 2003, you can raise the domain and then the forest functional levels by following these steps:

1.
Ensure that all domain controllers in the forest are upgraded to Windows Server 2003.

2.
Open Active Directory Domains and Trusts from the Administrative Tools.

3.
In the left pane, right-click Active Directory Domains and Trusts and then click Raise Domain Functional Level.

4.
In the Select an Available Domain Functional Level box, click Windows Server 2003 and then select Raise.

5.
Click OK and then OK again to complete the task.

6.
Repeat steps 15 for all domains in the forest.

7.
Perform the same steps on the forest root, except this time click Raise Forest Functional Level in step 3 and follow the prompts, as indicated in Figure 17.10.

Figure 17.10. Raising the forest functional level.

Note

The decision to raise the forest or domain functional levels is final. Be sure that any Windows 2000 domain controllers do not need to be added anywhere in the forest before performing this procedure. When the forest is Windows Server 2003 functional, this also includes being unable to add any Windows 2000 Active Directory subdomains.

After each domain functional level is raised, as well as the forest functional level, the Active Directory environment is completely upgraded and fully compliant with all the AD improvements made in Windows Server 2003. Functionality on this level opens the environment to features such as schema deactivation, domain rename, domain controller rename, and cross-forest trusts.

Moving AD-Integrated DNS Zones to Application Partition

The final step in a Windows Server 2003 Active Directory upgrade is to move any AD-integrated DNS zones into the newly created application partitions that Windows Server 2003 uses to store DNS information. To accomplish this, follow these steps:

1.
Open the DNS Microsoft Management Console snap-in (Start, All Programs, Administrative Tools, DNS).

2.
Navigate to DNS\<Servername>\Forward Lookup Zones.

3.
Right-click the zone to be moved and click Properties.

4.
Click the Change button to the right of the Replication description.

5.
Select either To All DNS Servers in the Active Directory Forest or To All DNS Servers in the Active Directory Domain, depending on the level of replication you want, as shown in Figure 17.11. Click OK when finished.

Figure 17.11. Moving AD-integrated zones.

6.
Repeat the process for any other AD-integrated zones.


Upgrading Separate AD Forests to a Single Forest Using Mixed-Mode Domain Redirect

Active Directory domains that are running in Windows 2000 Mixed mode can be joined into a separate forest without the need for domain migration tools or workstation reboots. To accomplish this, however, you must run a previously unknown process known as Mixed-Mode Domain Redirect on the environment.

Mixed-Mode Domain Redirect is useful in situations in which branch offices have deployed their own separate Active Directory forests, and the need later surfaces to join these disparate forests into a single, common forest. It is also useful in corporate acquisitions and mergers, where separate forests are suddenly required to merge into a single, unified directory.

Prerequisites and Limitations of the Mixed-Mode Domain Redirect Procedure

The first prerequisite for Mixed-Mode Domain Redirect is that each Active Directory domain in a forest must be running in Windows 2000 Mixed mode. If an organization needs to merge forests but has already gone to Windows 2000 Native mode, other procedures such as using the Active Directory Migration Tool v2.0 or synchronizing directories must be utilized instead.

A big caveat and limitation to this approach is that Windows 2000/XP/2003 clients may already view the domain as an Active Directory domain, requiring themselves to be rejoined to the domain or have their machine/domain password relationship reset using the netdom utility after the operation is complete. Unfortunately, there is no way around this as these client machines eventually discover that their NT domain has become an AD domain, and adjust themselves accordingly. Post-operation, it will become necessary to identify these machines and rejoin them to the new domain structure. This caveat does not hold true for Windows NT 4.0 clients, however.

In addition, this procedure also requires several reboots of existing domain controller servers and is subsequently best performed on a weekend or over a holiday.

Mixed-Mode Domain Redirect Procedure

The concept behind Mixed-Mode Domain Redirect is simple: Take an existing Active Directory domain, downgrade it to a Windows NT 4.0 domain, and upgrade it back into a different environment, as illustrated in Figure 17.12.

Figure 17.12. The Mixed-Mode Domain Redirect procedure.

The example in the diagrams and in the following sections is based on a fictional scenario. You can modify this scenario, however, to include any environment that satisfies the prerequisites outlined previously.

In this scenario, CompanyXYZ has been acquired by CompanyABC, and the need has arisen to merge the CompanyXYZ Windows 2000 forest with the CompanyABC Windows Server 2003 forest. Because the CompanyXYZ domain is running in Windows 2000 Mixed mode, the staff determined that using the Mixed-Mode Domain Redirect procedure would be the most straightforward approach, and there would be no need to change any client settings.

Establishing a Temporary Windows 2000 Domain Controller

The first step in the Mixed-Mode Domain Redirect process is identifying two temporary servers that will be needed in the migration. These servers do not necessarily need to be very fast servers because they will be used only for temporary storage of domain information.

The first temporary server should be set up as a Windows 2000 domain controller in the current Active Directory domain. After the operating system is loaded (Windows 2000 server or Advanced Server), you can run the dcpromo command to make it a domain controller in the current domain, per the standard Windows 2000 domain controller upgrade procedure. In addition, this domain controller does not need to be made into a global catalog server.

In our merger scenario, the temporary server SFDCTEMP01 is built with Windows 2000 and Service Pack 3 and added to the companyxyz.com Windows 2000 domain, where it becomes a domain controller, as illustrated in Figure 17.13. The current domain controllersSFDC01, SFDC02, LADC01, and SDDC01are illustrated as well. These four domain controllers will be migrated to the new environment.

Figure 17.13. Establishing a temporary domain controller.

Moving Operations Master Roles and Demoting Existing Domain Controllers

After the new server is introduced to an environment, the five OM roles must be moved from their existing locations and onto the temporary server. This can be done by using the nTDsutil utility. The steps to move OM roles were demonstrated previously in the "Moving Operation Master Roles" section of this chapter.

In the merger example, the schema master and domain naming master OM roles were moved from SFDC01 to SFDCTEMP01, and the OM roles of PDC Emulator, RID Master, and Infrastructure Master were moved from SFDC02 to SFDCTEMP01.

Demoting Production Domain Controllers

Because the old Active Directory forest will be retired, you need to run dcpromo on the remaining domain controller servers and demote them from domain controller duties. This effectively makes them member servers in the domain and leaves the only functional domain controller as the temporary server built in the preceding section.

In the merger example, as illustrated in Figure 17.14, SFDC01, SFDC02, LADC01, and SDDC01 are all demoted to member servers, and only SFDCTEMP01 remains as a domain controller.

Figure 17.14. Demoting production DCs.

Building a Temporary NT 4.0 Domain Controller

An NT Domain Controller will need to be built to allow the procedure to work. It must be brought up as an NT Backup Domain Controller (BDC) for the domain. Because there are no more NT domain controllers, the DC account for the computer must be created on the first temporary domain controller established. The DC account can be created by typing the following at a command prompt:

netdom add SFDCTEMP02 /domain:companyxyz.com /DC

It is important to note that even though the domain is in Mixed mode, the account must be created in advance if the Primary Domain Controller (PDC) function in the domain runs on a Windows 2000 domain controller; otherwise, the BDC cannot be added to the domain. When the account is established in advance, the second temporary domain controller must be built with Windows NT 4.0 and configured as a BDC in the domain that will be migrated. Because the domain is still in Windows 2000 Mixed mode, NT BDCs are still supported.

In the merger example, the second temporary domain controller is established as SFDCTEMP02 after the computer account is created on SFDCTEMP01 using the neTDom procedure just described. All existing computer and user accounts are copied into the SAM database on SFDCTEMP02.

Retiring the Existing Forest

The existing Windows 2000 forest can be safely retired by simply turning of the temporary Windows 2000 domain controller. Because this machine controls the OM roles, the Active Directory is effectively shut down. The added advantage of this approach is that you can resurrect the old domain if there are problems with the migration by turning on the first temporary server.

As illustrated in Figure 17.15, the SFDCTEMP01 server is shut off, retiring the companyxyz.com Active Directory domain. However, the COMPANYXYZ NetBIOS domain still exists in the SAM database of SFDCTEMP02, the NT BDC.

Figure 17.15. Retiring the old forest.

Promoting the Second Temporary Server to NT PDC

The NT BDC that you set up then needs to take over as the PDC for the domain, which effectively resurrects the old NetBIOS NT domain structure. This also leaves the domain in a position to be upgraded into an existing Active Directory structure.

In our example, the NT BDC SFDCTEMP02 is promoted to the PDC for the COMPANYXYZ NT domain, preparing it for integration with the companyabc.com Windows Server 2003 domain.

Promoting the NT PDC to Windows Server 2003 and Integrating with the Target Forest

Next, the NT PDC can be promoted to Windows Server 2003 Active Directory. This procedure upgrades all computer and user accounts to Active Directory, and the client settings will not need to be changed.

In the merger example, the Windows Server 2003 CD is inserted into the SCDCTEMP02 server, and a direct upgrade to Windows Server 2003 is performed. As part of the upgrade, the Active Directory Wizard allows the domain to be joined with an existing AD structure. In this case, the CompanyXYZ domain is added as a subdomain to the companyabc.com domain, effectively making it companyxyz.companyabc.com, as illustrated in Figure 17.16.

Figure 17.16. Redirecting the CompanyXYZ domain to the CompanyABC forest.

Re-establishing Prior Domain Controllers and Moving OM Roles

Another useful feature of this approach is that all the original servers that were domain controllers can be promoted back to their original functions without reloading the operating system. The DCPromo process can be run again on the servers, adding them as domain controllers for the domain in the new forest. In addition, the OM roles can be transferred as previously defined to move the original roles back to their old locations.

In our example, all the original domain controllers that are now member servers in the domain are re-promoted using DCPromo. SFDC01, SFDC02, LADC01, and SDDC01 are all re-added as domain controllers, and the proper OM roles are replaced, as illustrated in Figure 17.16.

Retiring the Temporary Domain Controller

The final step in the Mixed-Mode Domain Redirect is to retire the promoted NT BDC from the domain. The easiest way to accomplish this is to run DCPromo to demote it and then simply shut off the server. Both temporary servers can then be retired from duty and recycled into other uses.

In CompanyXYZ, the SCDCTEMP02 server is demoted using DCPromo and turned off. Overall, the procedure spares the company the need to change client logins, user settings, or server hardware and allows it to re-create the existing Windows 2000 domain within a different Windows Server 2003 Active Directory forest.


Consolidating and Migrating Domains Using the Active Directory Migration Tool v2.0

The development of Windows Server 2003 coincides with improvements in the Active Directory Migration Tool, a fully functional domain migration utility included on the Windows Server 2003 CD. ADMT version 2.0 allows Active Directory and NT domain users, computers, and groups to be consolidated, collapsed, or restructured to fit the design needs of an organization. In regard to Windows 2000 migrations, ADMT v2.0 provides for the flexibility to restructure existing domain environments into new Windows Server 2003 Active Directory environments, keeping security settings, user passwords, and other settings.

Understanding ADMT v2.0 Functionality

ADMT is an effective way to migrate users, groups, and computers from one domain to another. It is robust enough to migrate security permissions and Exchange mailbox domain settings; plus, it supports a rollback procedure in the event of migration problems. ADMT is composed of the following components and functionality:

  • ADMT migration wizards ADMT includes a series of wizards, each specifically designed to migrate specific components. You can use different wizards to migrate users, groups, computers, service accounts, and trusts.

  • Low client impact ADMT automatically installs a service on source clients negating the need to manually install client software for the migration. In addition, after the migration is complete, these services are automatically uninstalled.

  • SID history and security migrated Users can continue to maintain network access to file shares, applications, and other secured network services through migration of the SID History attributes to the new domain. This preserves the extensive security structure of the source domain.

  • Test migrations and rollback functionality An extremely useful feature in ADMT v2.0 is the capability to run a mock migration scenario with each migration wizard. This helps to identify any issues that may exist prior to the actual migration work. In addition to this functionality, the most recently performed user, computer, or group migration can be undone, providing for rollback in the event of migration problems.


Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT v2.0

ADMT v2.0 installs very easily but requires a thorough knowledge of the various wizards to be used properly. In addition, best-practice processes should be used when migrating from one domain to another.

The migration example in the following sections describes the most common use of the Active Directory Migration Tool: an interforest migration of domain users, groups, and computers into another domain. This procedure is by no means exclusive, and many other migration techniques can be used to achieve proper results. Subsequently, matching the capabilities of ADMT with the migration needs of an organization is important.

Using ADMT in a Lab Environment

ADMT v2.0 comes with unprecedented rollback capabilities. Not only can each wizard be tested first, but the last wizard transaction can also be rolled back in the event of problems. In addition, it is highly recommended that you reproduce an environment in a lab setting and that the migration process is tested in advance to mitigate potential problems that may arise.

You can develop the most effective lab by creating new domain controllers in the source and target domains and then physically segregating them into a lab network, where they cannot contact the production domain environment. The Operations Master (OM) roles for each domain can then be seized for each domain using the ntdsutil utility, which effectively creates exact replicas of all user, group, and computer accounts that can be tested with the ADMT.

ADMT v2.0 Installation Procedure

The ADMT component should be installed on a domain controller in the target domain, where the accounts will be migrated to. To install, follow these steps:

1.
Insert the Windows Server 2003 CD into the CD-ROM drive of a domain controller in the target domain.

2.
Choose Start, Run. Then type d:\i386\admt\admigration.msi, where d: is the drive letter for the CD-ROM drive, and press Enter.

3.
At the Welcome screen, as illustrated in Figure 17.17, click Next to continue.

Figure 17.17. Installing ADMT.

[View full size image]

4.
Accept the end-user license agreement (EULA) and click Next to continue.

5.
Accept the default installation path and click Next to continue.

6.
When ready to begin the installation, click Next at the next screen.

7.
After installation, click Finish to close the wizard.

ADMT Domain Migration Prerequisites

As previously mentioned, the most important prerequisite for migration with ADMT is lab verification. Testing as many aspects of a migration as possible can help to establish the procedures required and identify potential problems before they occur in the production environment.

That said, several functional prerequisites must be met before the ADMT can function properly. Many of these requirements revolve around the migration of passwords and security objects, and are critical for this functionality.

Creating Two-Way Trusts Between Source and Target Domains

The source and target domains must each be able to communicate with each other and share security credentials. Consequently, it is important to establish trusts between the two domains before running the ADMT.

Assigning Proper Permissions on Source Domain and Source Domain Workstations

The account that will run the ADMT in the target domain must be added into the Builtin\Administrators group in the source domain. In addition, each workstation must include this user as a member of the local Administrators group for the computer migration services to be able to function properly. Domain group changes can be easily accomplished, but a large workstation group change must be scripted, or manually accomplished, prior to migration.

Creating Target OU Structure

The destination for user accounts from the source domain must be designated at several points during the ADMT migration process. Establishing an organizational unit (OU) for the source domain accounts can help to simplify and logically organize the new objects. These objects can be moved to other OUs after the migration and this OU collapsed, if you want.

Modifying Default Domain Policy on the Target Domain

Unlike previous versions of Windows operating systems, Windows Server 2003 does not support anonymous users authenticating as the Everyone group. This functionality was designed in such as way as to increase security. However, for ADMT to be able to migrate the accounts, this functionality must be disabled. When the process is complete, the policies can be reset to the default levels. To change the policies, follow these steps:

1.
Open the Domain Security Policy (Start, All Programs, Administrative Tools, Domain Security Policy).

2.
Navigate to Security Settings\Local Policies\Security Options.

3.
Double-click Network Access: Let Everyone Permissions Apply to Anonymous Users.

4.
Check Define This Policy Setting and choose Enabled, as indicated in Figure 17.18. Click OK to finish.

Figure 17.18. Modifying the domain security policy.

5.
Repeat the procedure for the Domain Controller Security Policy snap-in.

Exporting Password Key Information

A 128-bit encrypted password key must be installed from the target domain on a server in the source domain. This key allows for the migration of password and SID History information from one domain to the next.

To create this key, follow these steps from the command prompt of a domain controller in the target domain where ADMT is installed:

1.
Insert a floppy disk into the drive to store the key. (The key can be directed to the network but, for security reasons, directing to a floppy is better.)

2.
Change to the ADMT directory by typing cd C:\program files\active directory migration tool and pressing Enter, where C: is the OS drive.

3.
Type admt key <SourceDomainName> a: <password>, where <SourceDomainName> is the NetBIOS name of the source domain, a: is the destination drive for the key, and <password> is a password that is used to secure the key. Refer to Figure 17.19 for an example. Then press Enter.

Figure 17.19. Exporting the password key.

[View full size image]

4.
Upon successful creation of the key, remove the floppy and keep it in a safe place.

Installing a Password Migration DLL on the Source Domain

A special password migration DLL must be installed on a domain controller in the source domain. This machine will become the Password Export Server for the source domain. The following procedure outlines this installation:

1.
Insert the floppy disk with the exported key from the target domain into the server's disk drive.

2.
Insert the Windows Server 2003 CD into the CD-ROM drive of the domain controller in the source domain where the Registry change will be enacted.

3.
Start the Password Migration Utility by choosing Start, Run and typing d:\i386\ADMT\Pwdmig\Pwdmig.exe, where d: is the drive letter for the CD-ROM drive.

4.
At the Welcome screen, click Next.

5.
Enter the location of the key that was created on the target domain; normally, this is the A: floppy drive, as indicated in Figure 17.20. Click Next to continue.

Figure 17.20. Setting up the password migration DLL.

[View full size image]

6.
Enter the password twice that was set on the target domain and click Next.

7.
At the Verification page, click Next to continue.

8.
Click Finish after the installation is complete.

9.
The system must be restarted, so click Yes when prompted to automatically restart. Upon restarting, the proper settings will be in place to make this server a Password Export Server.

Setting Proper Registry Permissions on the Source Domain

The installation of the proper components creates special Registry keys but leaves them disabled by default, for security reasons. You need to enable a specific Registry key to allow passwords to be exported from the Password Export Server. The following procedure outlines the use of the Registry Editor to perform this function:

1. | On a domain controller in the source domain, open the Registry Editor (Start, Run, Regedit).
2. | Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
3. | Double-click the AllowPasswordExport DWORD value.
4. | Change the properties from 0 to 1Hexadecimal.
5. | Click OK and close the Registry Editor.
6. | Reboot the machine for the Registry changes to be enacted.

At this point in the ADMT process, all prerequisites have been satisfied, and both source and target domains are prepared for the migration.

Migrating Groups

In most cases, the first objects to be migrated into a new domain should be groups. If users are migrated first, their group membership will not transfer over. However, if the groups exist before the users are migrated, they will automatically find their place in the group structure. To migrate groups using ADMT v2.0, use the Group Account Migration Wizard, as follows:

1.
Open the ADMT MMC snap-in (Start, All Programs, Administrative Tools, Active Directory Migration Tool).

2.
Right-click Active Directory Migration Tool in the left pane and choose Group Account Migration Wizard.

3.
Click Next to continue.

4.
On the next screen, shown in Figure 17.21, you can choose to test the migration. As mentioned previously, the migration process should be thoroughly tested before actually being placed in production. In this example, however, you want to perform the migration. Choose Migrate Now and click Next to continue.

Figure 17.21. Choosing to migrate in the Group Account Migration Wizard.

5.
Select the source and destination domains and click Next to continue.

6.
On the subsequent screen, you can select the group accounts from the source domain. Select all the groups required by using the Add button and selecting the objects manually. After you select the groups, click Next to continue.

7.
Enter the destination OU for the accounts from the source domain by clicking Browse and selecting the OU created in the steps outlined previously. Click Next to continue.

8.
On the following screen, there are several options to choose from that determine the nature of the migrated groups. Clicking the Help button details the nature of each setting. In the sample migration, choose the settings shown in Figure 17.22. After choosing the appropriate settings, click Next to continue.

Figure 17.22. Setting group options.

9.
If auditing is not enabled on the source domain, you will see the prompt shown in Figure 17.23. It gives you the option to enable auditing, which is required for migration of SID History. Click Yes to continue.

Figure 17.23. Enabling auditing.

10.
Another prompt may appear if auditing is not enabled on the target domain. Auditing is required for migration of SID History and can be disabled after the migration. Click Yes to enable and continue.

11.
A local group named SOURCEDOMAIN$$$ is required on the source domain for migration of SID History. A prompt asking to create this group is displayed at this point, as shown in Figure 17.24, if it was not created beforehand. Click Yes to continue.

Figure 17.24. Creating a local group.

12.
Another prompt may appear asking to create a Registry key named TcpipClientSupport in the source domain. Once again, this is required for SID History migration. Click Yes to continue.

13.
If you created the Registry key, an additional prompt then asks whether the PDC in the source domain will require a reboot. In most cases, it will, so click Yes to continue.

14.
The next prompt, shown in Figure 17.25, exists solely to stall the process while the reboot of the Source PDC takes place. Wait until the PDC is back online and then click OK to continue.

Figure 17.25. Waiting for the source domain PDC reboot.

15.
The subsequent screen allows for the exclusion of specific directory-level attributes from migration. If you need to exclude any attributes, they can be set here. In this example, no exclusions are set. Click Next to continue.

16.
Enter a user account with proper administrative rights on the source domain on the following screen. Then click Next to continue.

17.
Naming conflicts often arise during domain migrations. In addition, different naming conventions may apply in the new environment. The next screen, shown in Figure 17.26, allows for these contingencies. In this example, any conflicting names will have the XYZ- prefix attached to the account names. After defining these settings, click Next to continue.

Figure 17.26. Handling naming conflicts.

18.
The verification screen is the last wizard screen you see before any changes are made. Once again, make sure that the procedure has been tested before running it because ADMT will henceforth write changes to the Target Windows Server 2003 Active Directory environment. Click Finish when you're ready to begin group migration.

19.
The group migration process then commences. Changing the refresh rate, as shown in Figure 17.27, allows for a quicker analysis of the current process. When the procedure is complete, the log can be viewed by clicking View Log. After finishing these steps, click the Close button to end the procedure.

Figure 17.27. Altering the migration progress of group accounts.

Migrating User Accounts

User accounts are the "bread and butter" of domain objects and are among the most important components. The biggest shortcoming of ADMT v1.0 was its inability to migrate passwords of user objects, which effectively limited its use. However, ADMT v2.0 does an excellent job of migrating users, their passwords, and the security associated with them. To migrate users, follow these steps:

1.
Open the ADMT MMC snap-in (Start, All Programs, Administrative Tools, Active Directory Migration Tool).

2.
Right-click Active Directory Migration Tool and choose User Account Migration Wizard, as indicated in Figure 17.28.

Figure 17.28. Starting the User Account Migration Wizard.

3.
Click Next at the Welcome screen.

4.
The next screen offers the option to test the migration before actually performing it. As previously mentioned, this process is recommended, so for this example, perform the full migration. Select Migrate Now and then click Next.

5.
Select the source and target domains in the subsequent screen and click Next to continue.

6.
The following screen allows you to choose user accounts for migration. Just click the Add button and select the user accounts to be migrated. After you select all the user accounts, click Next to continue.

7.
The next screen, shown in Figure 17.29, allows you to choose a target OU for all created users. Choose the OU by clicking the Browse button. After you select it, click Next to continue.

Figure 17.29. Selecting the target OU.

8.
The new password migration functionality of ADMT v2.0 is enacted through the following screen. Select Migrate Passwords and then select the server in the source domain in which the Password Migration DLL was installed as covered in the "Installing a Password Migration DLL on the Source Domain" section. Click Next to continue.

Note

Depending on if other wizards have already been run, there may be additional steps at this point that happen one time only to set up proper registry settings, reboot DCs, and create special groups. These steps and dialog boxes are documented in steps 914 of the "Migrating Groups" section that precedes this section.

9.
The subsequent screen deals with security settings in relation to the migrated users. Click Help for an overview of each option. In this example, select the settings as shown in Figure 17.30. Then click Next to continue.

Figure 17.30. Setting the account transition options.

10.
Enter the username, password, and domain of an account that has Domain Admin rights in the source domain. Click Next to continue.

11.
Several migration options are presented as part of the next screen. As before, clicking Help elaborates on some of these features. In this example, select the options as shown in Figure 17.31. Click Next to continue.

Figure 17.31. Setting user options for the User Account Migration Wizard.

12.
The next screen is for setting exclusions. Specify any property of the user object that should not be migrated here. In this example, no exclusions are set. Click Next to continue.

13.
Naming conflicts for user accounts are common. Designate a procedure for dealing with duplicate accounts in advance and enter such information in the next wizard screen, as shown in Figure 17.32. Select the appropriate options for duplicate accounts and click Next to continue.

Figure 17.32. Setting naming conflict settings.

14.
The following verification screen presents a summary of the procedure that will take place. This is the last screen before changes are written to the target domain. Verify the settings and click Next to continue.

15.
The Migration Progress status box displays the migration process as it occurs, indicating the number of successful and unsuccessful accounts created. When the process is complete, review the log by clicking View Log and verify the integrity of the procedure. A sample log file from a user migration is shown in Figure 17.33. Click Close when finished.

Figure 17.33. Viewing a sample user migration log.

[View full size image]

Migrating Computer Accounts

Another important set of objects that must be migrated is also one of the trickier ones. Computer objects must not only be migrated in AD, but they must also be updated at the workstations themselves so that users will be able to log in effectively from their consoles. ADMT seamlessly installs agents on all migrated computer accounts and reboots them, forcing them into their new domain structures. Follow these steps to migrate computer accounts:

1.
Open the ADMT MMC snap-in (Start, All Programs, Administrative Tools, Active Directory Migration Tool).

2.
Right-click Active Directory Migration Tool and choose Computer Migration Wizard.

3.
Click Next at the Welcome screen.

4.
Just as in the previous wizards, the option for testing the migration is given at this point. It is highly recommended that you test the process before migrating computer accounts. In this case, because a full migration will take place, choose Migrate Now. Click Next to continue.

5.
Type the names of the source and destination domains in the drop-down boxes on the next screen and click Next to continue.

6.
In the following screen, select the computer accounts that will be migrated by clicking the Add button and picking the appropriate accounts. Click Next to continue.

7.
Select the OU the computer accounts will be migrated to and click Next to continue.

8.
The next screen allows for the option to specify which settings on the local clients will be migrated. Click the Help button for a detailed description of each item. In this example, select all items, as shown in Figure 17.34. Click Next to continue.

Figure 17.34. Specifying objects that will be translated.

9.
The subsequent screen prompts to choose whether existing security will be replaced, removed, or added to. In this example, replace the security. Click Next to continue.

10.
A prompt then informs you that the user rights translation will be performed in Add mode only. Click OK to continue.

11.
The next screen is important. It allows an administrator to specify how many minutes a computer will wait before restarting itself. In addition, you can define the naming convention for the computers, as shown in Figure 17.35. After choosing options, click Next to continue.

Figure 17.35. Selecting computer options.

12.
Just as in the previous wizards, exclusions can be set for specific attributes in the following wizard screen. Select any exclusions needed and click Next to continue.

13.
Naming conflicts are addressed in the subsequent screen. If any specific naming conventions or conflict resolution settings are required, enter them here. Click Next to continue.

14.
The Completion screen lists a summary of the changes that will be made. Review the list and click Finish when ready. All clients that will be upgraded are subsequently rebooted.

15.
When the migration process is complete, you can view the Migration log by clicking the View Log button. After verifying all settings, click Close.

16.
The client agents are subsequently distributed to all clients that have been migrated. Each agent is installed automatically and counts down until the designated time limit set during the configuration of the Computer Migration Wizard. At that point, the dialog box in Figure 17.36 appears on each workstation.

Figure 17.36. Notifying users of automatic workstation shutdown.

17.
Click Close on the ADMT MMC snap-in to end the wizard.

Migrating Other Domain Functionality

In addition to the Group, User, and Computer Migration Wizards, several other wizards can be used to migrate specific domain-critical components. These wizards operate using the same principles as those described in the preceding sections, and are as straightforward in their operation. The following is a list of the additional wizards included in ADMT v2.0:

  • Security Translation Wizard

  • Reporting Wizard

  • Service Account Migration Wizard

  • Exchange Directory Migration Wizard

  • Retry Task Wizard

  • Trust Migration Wizard

  • Group Mapping and Merging Wizard

Virtually all necessary functionality that needs replacing when migrating from one domain to another can be transferred by using ADMT v2.0. It has proven to be a valuable tool that gives administrators an additional option to consider when migrating and restructuring Active Directory environments.


Summary

Although Windows 2000 and Windows Server 2003 are close cousins in the operating system family tree, there are some compelling reasons to upgrade some, if not all, network components. The evolutionary nature of Windows Server 2003 makes performing this procedure more straightforward because the upgrade does not require major changes to Active Directory or operating system design. In addition, advanced procedures and tools such as Mixed-Mode Domain Redirect and ADMT v2.0 provide for a broad range of options to bring organizations to Windows Server 2003 functionality and closer to realizing the benefits that can be obtained through a migration.


Best Practices

  • Ensure that one of the post-upgrade tasks performed is an audit of all services so that servers that need IIS have the service re-enabled after migration.

  • Because prototype phases of a project are essential to test the design assumptions for a migration or implementation, create a production domain controller and then isolate it in the lab for testing.

  • Test the hardware compatibility of any server that will be directly upgraded to Windows Server 2003 against the published Hardware Compatibility List from Microsoft.

  • Because the decision to raise the forest or domain functional levels is final, ensure that there is no additional need to add Windows 2000 domain controllers anywhere in the forest before performing this procedure.

  • If the server or servers that hold the OM roles are not directly upgraded to Windows Server 2003 but will instead be retired, move these OM roles to another server.

  • When using ADMT, migrate groups into a new domain first to keep users' group membership intact.


Chapter 18. Compatibility Testing for Windows Server 2003

In This Chapter

  • The Importance of Compatibility Testing

  • Preparing for Compatibility Testing

  • Researching Products and Applications

  • Verifying Compatibility with Vendors

  • Lab-Testing Existing Applications

  • Documenting the Results of the Compatibility Testing

  • Determining Whether a Prototype Phase Is Required

At this point in the book, the new features of Windows Server 2003 have been presented and discussed in depth, as have the essential design considerations and migration processes. The goal of this chapter is to examine the process of testing the actual applications that rely on the Windows Server infrastructure.

This chapter provides insight into the steps necessary to gather information before the testing process begins, how to actually test the applications and document the results, and how to determine whether a more extensive prototype testing process is needed. Going through this process is vital to ensure the success of the project and avoid a displeased user community. The application testing process is intended as a quick way to validate the compatibility and functionality of the proposed end-state for the upgrade.

Currently many companies are seeking to "right-size" their network environment, and might be using the upgrade as a chance to actually reduce the number of servers that handle file and print processes on the network. At the end of the process, fewer servers will handle the same tasks as before, and new functionality might have been added, making the configurations of the individual servers that much more complex, and making it even more important to thoroughly test the mission-critical networking applications on the server. For example, Windows Server 2003 manages user connections and application server functions as well as providing enhanced fault tolerance capabilities, prompting some organizations to replace existing Windows NT4 or Windows 2000 servers with Windows Server 2003.

Thus it's even more important to test this configuration to ensure that the performance meets user expectations and that the everyday features used by the employees to share knowledge and collaborate are in place.

The results of the application compatibility testing process will validate the goals of the project or reveal goals that need to be modified because of application incompatibility or instability. If one key application simply won't work reliably on Windows Server 2003, a Windows NT4 Server or Windows 2000 Server might need to be kept as part of the networking environment, which changes the overall design. As discussed in Part II of this book, "Windows Server 2003 Active Directory," a variety of different combinations of Windows server configurations can be combined in the end configuration, so the chances that there will be a way to keep the troublesome applications working in the new environment are good.


The Importance of Compatibility Testing

The process presented in this chapter is an essential step to take in validating the design for the end-state of the migration or upgrade. The size of the organization and the breadth and scope of the upgrade are important factors to consider in determining the level of testing needed, and whether a full prototype should be conducted.

The differences between a prototype phase and an application testing phase can be dramatic or negligible based on the nature of the upgrade. A prototype phase replicates the end-state as completely as possible, often using the same hardware in the test lab that will be used in the production rollout.

Caution

Application testing can be performed on different hardware with different configurations than the end-state, but be aware that the more differences there are between the testing environment and the actual upgraded environment, the greater the risk for unexpected results. Essentially, you can do an application testing phase without a complete prototype phase, but you shouldn't do a prototype phase without a thorough application testing process.

Most network users don't know or care which server or how many servers perform which task or house which application, but they will be unhappy if an application no longer works after a migration to Windows Server 2003. If the organization already has Active Directory in place and is running Windows 2000 Servers, the risk of application incompatibility is likely to be less than if the organization is moving from an older operating system, such as NT 4 Server, or a competing operating system, such as Novell NetWare. The upgrade from Windows 2000 might well use the existing server hardware and perform inplace upgrades, or in the case of an upgrade from Windows NT4, it might involve implementing entirely new server hardware and new server fault tolerance features, which further change the operating environment. If this is the case, a full prototype phase might not be needed, but applications testing should still take place.


Preparing for Compatibility Testing

Although the amount of preparation needed will vary based on a number of factors, certain steps should be followed in any organizationthe scope of the testing should be identified (what's in and what's out), the goals of the testing process should be clarified, and the process should be mapped out.

A significant advantage of following a phased design methodology, as presented in Chapter 2, "Planning, Prototyping, Migrating, and Deploying Windows Server 2003 Best Practices," is in the planning discussions that take place and in the resulting statements of work, design, and migration documents that are created as deliverables. Often, companies' contract with migration experts to help companies avoid classic mistakes in the upgrade process. By the end of this planning process, it will be very clear why the project is happening, which departments need which features and capabilities, and what budget is available to perform the work. The timeline and key milestones also will be defined.

If a phased discovery and design process hasn't been followed, this information needs to be gathered to ensure that the testing process addresses the goals of the project stakeholders, and that the right applications are in fact tested and verified by the appropriate people.

Determining the Scope for Application Testing

At this point in the process, a list should be put together that clarifies which Windows Server 2003 version is to be used, which version of server software will be used, which add-in features are required, and which third-party applications are needed. As discussed previously, Windows Server 2003 comes in Web, Standard, Enterprise, and Datacenter versions. Smaller companies may choose to use the Standard versions of Windows Server 2003 operating system, whereas larger organizations might require the Enterprise version on their server systems for more advanced scalability and fault tolerance.

A key issue to discuss at this point is whether it is acceptable to have multiple versions of the Windows Server operating system in the final solution. Some organizations want to control standards on both software and support services, and require just a single network operating system.

Note

Although the Standard Edition of Windows Server 2003 is significantly cheaper than the Enterprise Edition of the license, cost should not be the primary reason for choosing one version over another. It is not as simple to upgrade from the Standard to Enterprise Edition as just changing a software license key. It requires either setting up a brand-new server with the Windows 2003 Enterprise Edition and migrating applications from server to server, or a full upgrade of the Enterprise Edition over an existing Standard Edition license. An organization should seriously consider whether it needs the functionality of the Enterprise Edition before choosing to buy and install the Standard Edition and attempting to upgrade later.

Third-party applications should be identified as well. The applications most often used include tape-backup software modules or agents, antivirus software, fax software, and voicemail integration products. Additional third-party add-on products might include the following:

  • Administration

  • Antispam

  • Backup and storage

  • Customer Relationship Management (CRM)

  • Log monitoring

  • Migration

  • Reporting

  • Security and encryption

The hardware to be used should be listed as well, to ensure that it is available when needed. Ideally the exact hardware to be used in the upgrade will be ordered for the application testing process, but if that is not possible, hardware with specifications similar to that of the servers that will eventually be used should be allocated. Although processor speed and amount of RAM will most likely not make a difference to whether the application functions properly on the server platform, certain hardware devices should be as similar as possible. Tape drives, for example, should have the same features as the ones to be used in the production environment, because this is one of the most critical components. If an autoloader will be used in the production environment, one should be made available for the application testing process. If faxing from the Outlook inbox is required, the same faxing hardware should be allocated as well.

Some applications require clients to be present for the testing process, so at least one workstation class system should be available for this purpose. Connectivity to the Internet might also be necessary for testing the functionality of remote access products and antivirus software.

A sample checklist of requirements for summarizing the scope of the application testing phase is shown in Table 18.1.

Table 18.1. Checklist for Application Testing

Server #1

Details (include version #s)

Server specs required:

Processor

RAM

Hard drive configuration

Other

Network OS and service packs:

Tape backup software version and agents:

Additional third-party apps required:

Additional hardware required:

SAN device

Tape drive

UPS

Switch/hub

Other

Internet access required?

Yes/No

This process should not take a great deal of time if previous planning has taken place. If the planning phase was skipped, some brainstorming will be required to ensure that the scope includes all the key ingredients required for the application testing. The goals for the application testing process will also affect the scope, which is covered in the following section.

Defining the Goals for Compatibility Testing

As with the previous step of defining the scope of the testing process, defining the goals might be a very quick process, or could require some discussions with the stakeholders involved in the project.

One useful way of looking at the goals for the project is to treat them as the checklist for successful completion of the testing. What conditions need to be met for the organization to confidently move forward with the next step in the Windows migration? The next step might be a more complete prototype testing phase. For smaller organizations, it might be a pilot rollout, where the new networking environment is offered to a select group of savvy users.

These goals are separate from the business goals the company might have, such as a more reliable network infrastructure or improved security. A more complete prototype phase could seek to address these goals while the application testing process stays focused on the performance of the specific combinations of the operating system and embedded and connected applications.

A convenient way to differentiate the goals of the project is to split them into key areas, as described in the following sections.

Timeframe for Testing

This goal can be defined with the statement "The testing must be completed in X days/weeks."

If there is very little time available to perform the testing, this limits how much time can be spent on each application and how many endusers can put each through its paces. It also necessitates a lesser degree of documentation. Remember to include time for researching the applications' compatibility with the vendors as part of the timeline. A quick project plan might be useful in this process as a way of verifying the assumptions and selling the timeline to the decisionmakers.

Estimating the Duration of the Application Testing Process

A good rule of thumb is to allow four hours per application to be tested for basic testing, and eight hours for a more thorough testing process. This allows time for the initial research with the vendors, configuration of the Windows 2003 operating system, and testing of the applications. Of course, the total time required will vary based on the types of applications to be tested.

For example, a Windows Server 2003 system with tape backup software and accounting software would take an estimated one or two days to test for basic compatibility and functionality, and potentially a week for more rigorous testing.

Note that if more than one resource is available to perform the testing, these configurations can be tested in parallel, shortening the duration of the process, but not the work effort.

It's always better to have some extra time during the testing phase. This time can be used for more extensive user testing, training, or documentation.

Contingency time should ideally be built into this goal. Resources assigned to the testing can get sick, or applications might require additional testing when problems are encountered. Vendors might not provide trial versions of the software as quickly as desired, or new versions of software or even the hardware itself can be delayed. With many companies seeking to consolidate the number of servers in use, it is not uncommon to see labs evolve through the testing process. Different versions of the Windows operating system are used, as are different versions of various application software programs.

Budget for the Testing

This goal can be defined with the statement "The testing must be completed within a budget of $X."

Of course, there might be no budget allocated for testing, but it's better to know this as soon as possible. A lack of budget means that no new hardware can be ordered, evaluation copies of the software (both Microsoft and the third-party applications) need to be used, and no external resources will be brought in. If the budget is available or can be accessed in advance of the production upgrade, a subset of the production hardware should be ordered for this phase. Testing on the exact hardware that will be used in the actual upgrade rather than a cast-off server will yield more valuable results.

Resources to Be Used

This goal can be defined with the statement "The testing will be completed by in-house resources and/or external consultants."

Often, the internal network administration staff is too busy with daily tasks or tackling emergencies that spring up (which might be the reason for the upgrade in the first place), and staff personnel should not be expected to dedicate 100% of their time to the testing process.

If an outside consulting firm with expertise in Windows Server 2003 is going to be used in the testing process, it can be a good leverage point to have already created and decided upon an internal budget for the testing process. This cuts down on the time it takes to debate the approaches from competing firms.

Extent of the Testing

The extent of compatibility testing can be defined with the statement "Each application will be tested for basic, mid-level, or complete compatibility and feature sets."

This goal might be set for different types of applications where some mission-critical applications would need to have extensive testing, whereas less critical applications might have more basic testing performed. A short timeframe with a tightly limited budget won't allow extensive testing, so basic compatibility will most likely be the goal.

Defining the Different Levels of Compatibility Testing

Basic compatibility testing, as used in this chapter, essentially means that the mission-critical applications are tested to verify that they load without errors and perform their primary functions properly with Windows Server 2003. Often the goal with basic testing is to simply see whether the application works, without spending a lot of time or money on hardware and resources, and with a minimum amount of documentation and training. Note that this level of testing reduces but does not eliminate the risks involved in the production rollout.

Mid-level testing is defined as a process whereby Windows Server 2003 is configured with all the applications that will be present in the eventual implementation, so that the test configuration matches the production configuration as closely as possible to reduce the chance of surprise behavior during the rollout. This level of testing requires more preparation to understand the configuration and more involvement from testing resources, and should include endusers. Some training should take place during the process, and documentation is created to record the server configurations and details of the testing process. Although this level of testing greatly reduces the risks of problems during the production migration or upgrade, the migration process of moving data between servers and training the resources on this process hasn't been covered, so some uncertainty still exists.

Complete testing adds additional resource training and possibly end-user training during the process, and should include testing of the actual migration process. Complete training requires more documentation to record the processes required to build or image servers and perform the migration steps. Complete testing is what is typically defined as a prototype phase.

Training Requirements During Testing

This goal can be defined with the statement "Company IT resources will/will not receive training during the application testing process."

Although the IT resources performing the testing will learn a great deal by going through the testing process, the organization might want to provide additional training to these individuals, especially if new functionality and applications are being tested. If external consultants are brought in, it is important that the organization's own resources are still involved in the testing process for training and validation purposes. The application testing phase might be an excellent time to have help desk personnel or departmental managers in the user community learn more about new features that will soon be offered so they can help support the user community and generate excitement for the project.

Documentation Required

This goal can be defined with the statement "Documentation will/will not be generated to summarize the process and results."

Again, the budget and timeline for the testing will affect the answer to this question. Many organizations require a paper trail for all testing procedures, especially when the Windows infrastructure will have an impact on the viability of the business itself. For other organizations, the networking environment is not as critical, and less or no documentation may be required.

The application testing phase is a great opportunity to document the steps required for application installations or upgrades if time permits, and this level of instruction can greatly facilitate the production rollout of the upgraded networking components.

Extent of User Community Involvement

This goal can be defined with the statement "Endusers will be included/not included in the testing process."

If there are applications such as Customer Relationship Management (CRM), document routing, voicemail or paging add-ons, or connectivity to PDAs and mobile devices, a higher level of user testing (at least from the power users and executives) should be considered.

Fate of the Testing Lab

This goal can be defined with the statement "The application testing lab will/will not remain in place after the testing is complete."

There are a number of reasons that organizations decide to keep labs in place after their primary purpose has been served. Whenever a patch or upgrade to Windows Server 2003 or to a third-party application integrates with Windows Server 2003, it is advisable to test it in a nonproduction environment. Even seemingly innocent patches to antivirus products can crash a production server. Other updates might require user testing to see whether they should be rolled out to the production servers.

Documenting the Compatibility Testing Plan

The information discussed and gathered through the previous exercises needs to be gathered and distributed to the stakeholders to assure that the members of the team are working toward the same goals. These components are the scope and the goals of the application testing process, and should include timeline, budget, extent of the testing (basic, mid-level, complete), training requirements, documentation requirements, and the fate of the testing lab. This step is even more important if a formal discovery and design phase was not completed.

By taking the time to document these constraints, the testing process will be more structured and less likely to miss a key step or get bogged down on one application. The individuals performing the testing will essentially have a checklist of the exact testing process, and are less likely to spend an inordinate amount of time on one application, or "get creative" and try products that are not within the scope of work. After the testing is complete, the stakeholders will also have made it clear what is expected in terms of documentation so the results of the testing can be presented and reviewed efficiently.

This summary document should be presented to the stakeholders of the project for review and approval. The organization will then be ready to proceed with the research and testing process for Windows Server 2003 compatibility.


Researching Products and Applications

The next step in the compatibility-testing process is to actually begin research on the products and applications being tested. With the documented goals and expectations of the necessary compatibility-testing process, the organization can proceed with information gathering.

Taking Inventory of Network Systems

The first step of the information-gathering process is to take inventory of the network systems that will be part of the Windows Server 2003 environment. These systems include domain controllers, application servers, gateway systems, and utility servers.

Note

When you're identifying the systems that are part of the Windows Server 2003 environment, you should create separate lists that note whether a server is a domain controller or member server of the environment, or whether the server is standalone and does not directly interact with the domain. Usually, standalone servers that are not integrated into the domain are significantly less likely to require a parallel upgrade to Windows Server 2003. Because the system is operating as a standalone, it will typically continue to operate in that manner and can be removed from the scope of testing and migration during the initial migration phase. Removing this server can also greatly minimize the scope of the project by limiting the number of servers that need to be included in the testing and migration process.

For systems that are part of the network domain, the devices should be identified by which network operating system they are running. A sample system device inventory sheet is shown in Table 18.2.

Table 18.2. System Device Inventory Table

Server Name

Member of Domain (Y/N)

Domain Controller (Y/N)

General Functions

Operating System

SERVER-A

Y

Y

DC, DNS, DHCP

Windows 2000 SP3

SERVER-B

Y

N

Exchange Server

Windows 2000 SP3

SERVER-C

Y

N

File/Print Server

Windows NT4

SERVER-D

N

N

WWW Web Server

Windows 2000 SP3

Taking Inventory of Applications on Existing Servers

Now that you have a list of the server systems on your network, the next step is to take inventory of the applications running on the systems. Care should be taken to identify all applications running on a system, including tape software, antivirus software, and network monitoring and management utilities.

The primary applications that need to be upgraded will be obvious, as well as the standard services such as data backup and antivirus software. However, in most organizations, additional applications hiding on the network need to be identified. If the Systems Management Server (SMS) is in use, or another network management tool with inventorying capabilities, it should also be able to provide this basic information.

Note

Another angle to validating that all applications are tested before a migration is to simply ask all departmental managers to provide a list of applications that are essential for them and their employees. This takes the opposite angle of looking not at the servers and the applications, but looking at what the managers or employees in the organization say they use as part of their job responsibilities. From these lists, you can put together a master list.

Understanding the Differences Between Applications and Windows Services

We need to make a distinction as it pertains to the Windows Server 2003 operating environment. Applications are programs that run on top of Windows Server 2003, such as application tools or front-end services, and services are programs that integrate with the operating system, such as SQL, Exchange, antivirus applications, and the like. As discussed previously, in the .NET Framework, applications are designed to sit on top of the Windows platform, so the more embedded the legacy application is in the NOS, the greater the potential for problems.

It is also helpful to separate the Microsoft and non-Microsoft applications and services. The Microsoft applications that are to be upgraded to the new Windows Server 2003 environment are likely to have been thoroughly tested by Microsoft. Possible incompatibilities should have been identified, and a great deal of information will be available on Microsoft TechNet or on the Microsoft product page of its Web site. On the other hand, for non-Microsoft applications and services, weeks could pass after a product's release before information regarding any compatibility problems with the Microsoft operating system surfaces. This is also true for service packs and product updates where problems may be made public weeks or months after the release of the update.

Furthermore, many organizations that create custom applications will find that little information is available on Windows Server 2003 compatibility, so they could require more complex lab tests to validate compatibility.

Completing an Inventory Sheet per Application

An organization should create an inventory sheet for each application being validated. Having an inventory sheet per application may result in dozens, if not hundreds, of sheets of paper. However, each application needs to go through extensive verification for compatibility, so the information gathered will be helpful.

A sample product inventory sheet includes the following categories:

  • Vendor name

  • Product name

  • Version number

  • Application or service?

  • Mission-critical?

  • Compatible with Windows Server 2003 (Y/N)?

  • Vendor-stated requirements to make compatible

  • Decision to migrate (update, upgrade, replace, remain on existing OS, stop using, proceed without vendor support)

Additional items that might be relevant could include which offices or departments use the application, how many users need it, and so on.

Any notes from the vendor, such as whitepapers for migration, tip/trick migration steps, upgrade utilities, and any other documentation should be printed, downloaded, and kept on file. Although a vendor might state that a product is compatible on its Web site today, you might find that by the time an upgrade occurs, the vendor has changed its statement on compatibility. Any backup information that led to the decision to proceed with the migration might also be useful in the future.

Prioritizing the Applications on the List

After you complete and review the list, you will have specific information showing the consensus of which applications are critical and which are not.

There is no need to treat all applications and utilities with equal importance because a simple utility that does not work and is not identified as a critical application can be easily upgraded or replaced later and should not hold up the migration. On the other hand, problems with a mission-critical business application should be reviewed in detail because they might affect the whole upgrade process.

Remember that certain utility applications should be considered critical to any network environment. These include tape backup (with the appropriate agents) and virus-protection software. In organizations that perform network and systems management, management tools and agents are also essential.


Verifying Compatibility with Vendors

Armed with the full list of applications that need to be tested for compatibility, the application testing team can now start hitting the phones and delving into the vendors' Web sites for the compatibility information.

For early adopters of certain application software programs, more research might be necessary because vendors tend to lag behind in publishing statements of compatibility with new products. Past experience has shown that simply using the search feature on the vendor's site can be a frustrating process, so having an actual contact who has a vested interest in providing the latest and greatest information (such as the company's sales representative) can be a great timesaver.

Each vendor tends to use its own terminology when discussing Windows Server 2003 compatibility (especially when it isn't 100% tested); a functional way to define the level of compatibility is with the following four areas:

  • Compatible

  • Compatible with patches or updates

  • Not compatible (requires version upgrade)

  • Not compatible and no compatible version available (requires new product)

When possible, it is also a good practice to gather information about the specifics of the testing environment, such as the version and SP level of the Windows operating system the application was tested with, along with the hardware devices (if applicable, such as tape drives, specific PDAs, and so forth) tested.

Tracking Sheets for Application Compatibility Research

For organizational purposes, a tracking sheet should be created for each application to record the information discovered from the vendors. A sample product inventory sheet includes the following categories:

  • Vendor name

  • Product name and version number

  • Vendor contact name and contact information

  • Level of criticality: critical, near-critical, nice to have

  • Compatible with Windows Server 2003: yes/no/did not say

  • Vendor-stated requirements to upgrade or make application compatible

  • Recommended action: None, patch/fix/update, version upgrade, replace with new product, stop using product, continue using product without vendor support

  • Operating system compatibility: Windows Server 2003, Windows 2000 Server, Windows NT Server, other

  • Notes (conversation notes, URLs used, copies of printed compatibility statements, or hard copy provided by vendor)

It is a matter of judgment as to the extent of the notes from discussions with the vendors and materials printed from Web sites that are retained and included with the inventory sheet and kept on file. Remember that URLs change frequently, so it makes sense to print the information when it is located.

In cases where product upgrades are required, information can be recorded on the part numbers, cost, and other pertinent information.

Six States of Compatibility

There are essentially six possible states of compatibility that can be defined, based on the input from the vendors, and that need to be verified during the testing process. These levels of compatibility roughly equate to levels of risk of unanticipated behavior and issues during the upgrade process:

  1. The application version currently in use is Windows Server 2003-compatible.

  2. The application version currently in use is compatible with Windows Server 2003, with a minor update or service patch.

  3. The application currently in use is compatible with Windows Server 2003, with a version upgrade of the application.

  4. The application currently in use is not Windows Server 2003-compatible and no upgrade is available, but it will be kept running as is on an older version of Windows Server (or other network operating systems) in the upgraded Windows Server 2003 networking environment.

  5. The application currently in use is not Windows Server 2003-compatible, and will be phased out and not used after the upgrade is complete.

  6. The application currently in use is not Windows Server 2003-compatible per the vendor, or no information on compatibility was available, but it apparently runs on Windows Server 2003 and will be run only on the new operating system.

Each of these states is discussed in more detail in the following sections.

Using a Windows Server 2003-Compatible Application

Although most applications require some sort of upgrade, the vendor might simply state that the version currently in use will work properly with Windows Server 2003 and provide supporting documentation or specify a URL with more information on the topic. This is more likely to be the case with applications that don't integrate with the Windows Server components, but instead interface with certain components, and might even be installed on separate servers.

It is up to the organization to determine whether testing is necessary to verify the vendor's compatibility statement. If the application in question is critical to the integrity or security of the Windows 2003 operating system, or provides the users with features and capabilities that enhance their business activities and transactions, testing is definitely recommended. For upgrades that have short timeframes and limited budgets available for testing (basic testing as defined earlier in the chapter), these applications may be demoted to the bottom of the list of priorities and would be tested only after the applications requiring updates or upgrades had been tested.

A clear benefit of the applications that the vendor verifies as being Windows Server 2003-compatible is that the administrative staff will already know how to install and support the product and how it interfaces with Windows 2003 and the help desk; endusers won't need to be trained or endure the learning curves required by new versions of the products.

Note

As mentioned previously, make sure to clarify what NOS and which specific version of Windows operating system was used in the testing process, because seemingly insignificant changes, such as security patches to the OS, can influence the product's performance in your upgraded environment. Tape backup software is notorious for being very sensitive to minor changes in the version of Windows, and tape backups can appear to be working when they aren't. If devices such as text pagers or PDAs are involved in the process, the specific operating systems tested and the details of the hardware models should be verified if possible to make sure that the vendor testing included the models in use by the organization.

If a number of applications are being installed on one Windows Server 2003 system, unpredictable conflicts are possible. Therefore, testing is still recommended for mission-critical Windows Server 2003 applications, even for applications the vendor asserts are fully compatible with Windows Server 2003.

Requiring a Minor Update or Service Patch for Compatibility

When upgrading from Windows 2000, many applications simply need a relatively minor service update or patch for compatibility with Windows Server 2003. This is less likely to be the case when upgrading from Windows NT4 or a completely different operating system, such as Novell NetWare or Linux.

During the testing process, the service updates and patches are typically quick and easy to install, are available over the Internet, and are often free of charge. It is important to read any notes or readme files that come with the update because specific settings in the Windows Server 2003 configuration might need to be modified for them to work. These updates and patches tend to change and be updated themselves after they are released, so it is worth checking periodically to see whether new revisions have become available.

These types of updates generally do not affect the core features or functionality of the products in most cases, although some new features may be introduced; so they have little training and support ramifications because the help desk and support staff will already be experienced in supporting the products.

Applications That Require a Version Upgrade for Compatibility

In other cases, especially when migrating from Windows NT4 or another network operating system, a complete migration strategy is required, and this tends to be a more complex process than downloading a patch or installing a minor update to the product. The process will vary by product, with some allowing an inplace upgrade, where the software is not on the Windows Server 2003 server itself, and others simply installing from scratch.

The amount of time required to install and test these upgrades is greater and the learning curve steeper, and the danger of technical complexities and issues increases. Thus additional time should be allowed for testing the installation process of the new products, configuring them for optimal Windows connectivity, and fine-tuning for performance factors. Training for the IT resources and help desk staff will be important because of the probability of significant differences between the new and old versions.

Compatibility with all hardware devices should not be taken for granted, whether it's the server itself, tape backup devices, or SAN hardware.

If a new version of the product is required, it can be difficult to avoid paying for the upgrade, so budget can become a factor. Some vendors can be persuaded to provide evaluation copies that expire after 30120 days.

Handling an Incompatible Application That Will Remain "As Is"

As discussed earlier in this chapter, Windows Server 2003 can coexist with previous versions of the Windows operating system, so a Windows Server 2003 migration does not require that every server be upgraded. In larger organizations, for example, smaller offices might choose to remain on Windows 2000 for a period of time, if there are legitimate business reasons or cost concerns with upgrading expensive applications. If custom scripts or applications have been written that integrate and add functionality to Windows NT4 or Windows 2000, it might make more sense to simply keep those servers intact on the network.

Although it might sound like an opportunity to skip any testing because the server configurations aren't changing, connectivity to the new Windows Server 2003 configurations still need to be tested, to ensure that the functionality between the servers is stable. Again, in this scenario the application itself is not upgraded, modified, or changed, so there won't be a requirement for administrative or end-user training.

Incompatible Applications That Won't Be Used

An organization might decide that because an application is incompatible with Windows Server 2003, no upgrade is available, or the cost is prohibitive, so it will simply retire it. Windows Server 2003 includes a variety of new features, as discussed throughout the book, that might make certain utilities and management tools unnecessary. For example, a disaster recovery module for a tape backup product might no longer be necessary after clustering is implemented.

Care should be taken during the testing process to note the differences that the administrative, help desk, and endusers will notice in the day-to-day interactions with the networking system. If features are disappearing, a survey to assess the impact can be very helpful. Many users will raise a fuss if a feature suddenly goes away, even if it was rarely used, whereas the complaints could be avoided if they had been informed in advance.

Officially Incompatible Applications That Seem to Work Fine

The final category applies to situations in which no information can be found about compatibility. Some vendors choose to provide no information and make no stance on compatibility with Windows Server 2003. This puts the organization in a tricky situation, as it has to rely on internal testing results to make a decision. Even if the application seems to work properly, the decision might be made to phase out or retire the product if its failure could harm the business process. If the application performs a valuable function, it is probably time to look for or create a replacement, or at least to allocate time for this process at a later time.

If the organization chooses to keep the application, it might be kept in place on an older version of Windows or moved to the new Windows Server 2003 environment. In either case, the administrative staff, help desk, and endusers should be warned that the application is not officially supported or officially compatible and might behave erratically.

Creating an Upgrade Decision Matrix

Although each application will have its own inventory sheet, it is helpful to put together a brief summary document outlining the final results of the vendor research process and the ramifications to the network upgrade project. Table 18.3 provides a sample format for the upgrade decision matrix.

Table 18.3. Upgrade Decision Matrix

Item #

Vendor

Product Name

Version

Windows 2003
Compatibility Level:
1) Compatible as is
2) Needs patches
3) Needs upgrade
4) Not compatible

Decision:
(N) No change
(P) Patch/fix
(U) Upgrade
(R) Replace

1

Veritas

BackUp Exec

v.x

2

U

2

Veritas

Open File Agent

v.x

3

U

3

TrendMicro

InterScan

v.x

3

U

4

Microsoft

Exchange

2003

1

N

As with all documents that affect the scope and end-state of the network infrastructure, this document should be reviewed and approved by the project stakeholders.

This document can be expanded to summarize which applications will be installed on which network server if there are going to be multiple Windows Server 2003 servers in the final configuration. In this way, the document can serve as a checklist to follow during the actual testing process.

Assessing the Effects of the Compatibility Results on the Compatibility Testing Plan

After all the data has been collected on the compatibility, lack of compatibility, or lack of information, the compatibility testing plan should be revisited to see whether changes need to be made. As discussed earlier in the chapter, the components of the compatibility testing plan are the scope of the application testing process and the goals of the process (timeline, budget, extent of the testing, training requirements, documentation requirements, and fate of the testing lab).

Some of the goals might now be more difficult to meet, and require additional budget, time, and resources. If essential network applications need to be replaced with version upgrades or a solution from a different vendor, additional time for testing and training might also be required. Certain key endusers might also need to roll up their sleeves and perform hands-on testing to make sure that the new products perform to their expectations.

This might be the point in the application testing process at which a decision is made that a more complete prototype testing phase is needed, and the lab would be expanded to more closely, or exactly, resemble the end-state of the migration.


Lab-Testing Existing Applications

With the preparation and research completed and the compatibility testing plan verified as needed, the actual testing can begin. The testing process should be fairly anticlimactic at this point because the process has been discussed at length, and it will be clear what the testing goals are and which applications will be tested. Due diligence in terms of vendor research should be complete, and now it is just a matter of building the test server or servers and documenting the results.

The testing process can yield unforeseen results because the exact combination of hardware and software might affect the performance of a key application; but far better to have this occur in a nonproduction environment in which failures won't affect the organization's ability to deliver its services.

During the testing process, valuable experience with the installation and upgrade process will be gained and will contribute to the success of the production migration. The migration team will be familiar withor possibly experts atthe installation and application migration processes when it counts, and are more likely to avoid configuration mistakes and resolve technical issues.

Allocating and Configuring Hardware

Ideally, the budget will be available to purchase the same server hardware and related peripherals (such as tape drives, UPSs, PDAs, text pagers) that will be used in the production migration. This is preferable to using a server machine that has been sitting in a closet for an undetermined period of time, which might respond differently than the eventual hardware that will be used. Using old hardware can actually generate more work in the long run and adds more variables to an already complex process.

If the testing process is to exactly mirror the production environment, this would be considered to be a prototype phase, which is generally broader in scope than compatibility testing, and requires additional hardware, software, and time to complete. A prototype phase is recommended for more complex networks in which the upgrade process is riskier and more involved and in which the budget, time, and resources are available.

Don't forget to allocate a representative workstation for each desktop operating system that is supported by the organization and a sample remote access system, such as a typical laptop or PDA that is used by the sales force or traveling executive.

Allocating and Configuring Windows Server 2003

By this point, the software has been ordered, allocated, downloaded, and set aside for easy access, along with any notes taken or installation procedures downloaded in the research phase. If some time has elapsed since the compatibility research with the vendors, it is worth checking to see whether any new patches have been released. The upgrade decision matrix discussed earlier in the chapter is an excellent checklist to have on hand during this process to make sure that nothing is missed that could cause delays during the testing process.

When configuring the servers with the appropriate operating systems, the company standards for configurations should be adhered to, if they have been documented. Standards can include the level of hard drive redundancy, separation of the application files and data files, naming conventions, roles of the servers, approved and tested security packs, and security configurations.

Next, Windows Server 2003 should be configured to also meet company standards and then for the essential utilities that will protect the integrity of the data and the operating system, which typically include the backup software, antivirus software, and management utilities and applications. After this base configuration is completed, it can be worth performing a complete backup of the system or using an application such as Ghost to take a snapshot of the server configuration in case the subsequent testing is problematic and a rollback is necessary.

Loading the Remaining Applications

With Windows Server 2003 configured with the core operating system and essential utilities, the value-added applications can be tested. Value-added applications enhance the functionality of Windows and enable the users to perform their jobs more efficiently and drive the business more effectively. It's helpful to provide a calendar or schedule to the endusers who will be assisting in the testing process at this point so they know when their services will be needed.

There are so many different combinations of applications that might be installed and tested at this point that the different permutations can't all be covered in this chapter. As a basic guideline, first test the most essential applications and the applications that were not identified previously as being compatible. By tackling the applications that are more likely to be problematic early on in the process, the testing resources will be fresh and any flags can be raised to the stakeholders while there is still time left in the testing process for remediation.

Thorough testing by the endusers is recommended, as is inclusion of the help desk staff in the process. Notes taken during the testing process will be valuable in creating any configuration guides or migration processes for the production implementation.

Note

Beyond basic functionality, data entry, and access to application-specific data, some additional tests that indicate an application has been successfully installed in the test environment include printing to different standard printers, running standard reports, exporting and importing data, and exchanging information with other systems or devices. Testing should be done by endusers of the application and administrative IT staff who support, maintain, and manage the application. Notes should be taken on the process and the results because they can be very useful during the production migration.

Application Compatibility Testing Tool

Microsoft offers a tool called the Windows Application Compatibility Toolkit (ACT), which is a collection of documents and tools that can help identify compatibility problems on applications that are installed on a Windows 2000 or 2003 Server. The Windows Application Compatibility Toolkit can be very helpful in determining whether the application in questionespecially an application where no information is provided by the vendor or a custom applicationhas obvious problems or potential security holes. This level of testing falls under the medium level or complete levels of testing, mentioned previously in this chapter, which is valuable to organizations with more complex Windows networking environments that need to be as stable as possible.

There are three components to this tool: the Microsoft Application Compatibility Analyzer, the Windows Application Verifier, and the Compatibility Administrator.

The Application Compatibility Analyzer, shown in Figure 18.1, gathers an inventory of all the applications running on the server and then cross-references the results online with a database maintained by Microsoft to produce an assessment report.

Figure 18.1. Windows Application Compatibility Analyzer.

[View full size image]

For application development, Windows Applications Verifier then tests for potential compatibility errors caused by common programming mistakes, checks the application for memory-related issues, determines an application's compliance with requirements of the "Certified for Windows Server 2003" Logo Programs, and looks for potential security issues in an application.

At the time of this writing, this application is available for download from http://www.microsoft.com/downloads by performing a search for the phrase "application compatibility toolkit."

Testing the Migration and Upgrade Process

This section touches on the next logical step in the testing process. After it has been verified that the final configuration agreed upon in the planning process is stable and which applications and utilities will be installed on which server, the actual upgrade process can be tested. As discussed in Chapters 16, "Migrating from Windows NT4 to Windows Server 2003," and 17, "Migrating from Windows 2000 to Windows Server 2003," Windows Server 2003 comes with a number of built-in migration testing and facilitating utilities and tools.


Documenting the Results of the Compatibility Testing

A number of documents can be produced during the compatibility testing process. Understanding the expectations of the stakeholders and what the documents will be used for is important. For example, more detailed budgetary information might need to be compiled based on the information, or go/no go decisions might need to be reached. Thus a summary of the improvements offered by Windows Server 2003 in the areas of reliability, performance visible to the user community, and features improved and added, might need to be presented in a convincing fashion.

At a minimum, a summary of the testing process should be created, and a final recommendation for the applications to be included in the production upgrade or migration should be provided to the stakeholders. This can be as simple as the upgrade decision matrix discussed earlier in the chapter, or it can be more thorough, including detailed notes of the exact testing procedures followed. Notes can be made available summarizing the results of endusers testing, validating the applications, and describing resultsboth positive and negative.

If the testing hardware is the same as the hardware that will be used in the production upgrade, server configuration documents that list the details of the hardware and software configurations can be created; they will ensure that the servers built in the production environment will have the same fundamental configuration as was tested in the lab.

A more detailed build document can be created that walks the technician through the exact steps required to build the Windows Server 2003 system, in cases where many network servers need to be created in a short period of time.

The level of effort or the amount of time to actually perform the upgrade or the migration of a sample subdirectory can be recorded as part of the documentation, and this information can be very helpful in planning the total amount of time that will be required to perform the upgrade or migration.


Determining Whether a Prototype Phase Is Required

The issue of whether a more complete prototype phase is needed or if a more limited application compatibility testing phase is sufficient has come up several times in this chapter. The essential difference between the two is that the prototype phase duplicates as exactly as possible the actual end-state of the upgrade, from server hardware to peripherals and software, so that the entire upgrade process can be tested to reduce the chance of surprises during the production upgrade. The application testing phase can be less extensive, involve a single server, and be designed to verify that the applications required will work reliably on the Windows Server 2003 configuration. Compatibility testing can take as little time as a weekfrom goal definition, to research, to actual testing. A prototype phase takes considerably longer because of the additional steps required.

The following is a checklist that will help your organization make the decision:

  • Is sufficient budget available for a subset of the actual hardware that will be used in the upgrade?

  • Is sufficient time available for the configuration of the prototype lab and testing of the software?

  • Are the internal resources available for a period of time long enough to finish the prototype testing? Is the budget available to pay for external consulting resources to complete the work?

  • Is the Windows networking environment mission-critical to the business' capability to go about its daily activities and generate revenues, and will interruption of Windows services cost the company an unacceptable amount of money?

  • Does the actual migration process need to be tested and documented to ensure the success of the upgrade?

  • Do resources need to be trained on the upgrade process (building the servers, configuring the network operating system and related applications)?

If you find that the answer to more than half of these questions is yes, it's likely that a prototype phase will be required.


Summary

Windows Server 2003 compatibility testing should be performed before any upgrade or migration. The process can be completed very quickly for smaller networks (basic testing) or for larger networks with fairly simple networking environments.

The first steps include identifying the scope and goals of the project to make sure that the stakeholders are involved in determining the success factors for the project. Then research needs to be performed, internal to the company, on which in-place applications are network-related. This includes not only Windows Server, but tape backup software, antivirus software, network management and monitoring tools, add-ons, and inventory sheets created summarizing this information. Decisions as to which applications are critical, near-critical, or just nice to have should also be made. Research should then be performed with the vendors of the products, tracking sheets should be created to record this information, and the application should be categorized in one of six states of compatibility. Next the testing begins, with the configuration of the lab environment that is isolated from the production network, and the applications are loaded and tested by both administrative and enduser or help desk staff. The results are then documented, and the final decisions of whether to proceed are made.

With this process, the production upgrade or migration is smoother, and the likelihood of technical problems that can harm the business' ability to transact or provide its services is greatly reduced. The problems are identified beforehand and resolved, and the resources who will perform the work gain familiarity with all the products and processes involved.


Best Practices

  • Take the time to understand the goals of the project (What will the organization gain by doing the upgrade?) as well as the scope of the project (What is included and what is excluded from the project?).

  • Understand all the applications that connect with Windows Server 2003 and whether they are critical, near-critical, or simply nice to have.

  • Document the research process for each application, because this will prove to be very valuable if problems are encountered during the testing process.

  • Create a lab environment that is as close to the final end-state of the upgrade as possible. This reduces the variables that can cause problems at the least opportune time.

  • Test applications for compatibility with both typical endusers of the application and application administrators who support, maintain, and manage the application.


Part VI: Windows Server 2003 Administration and Management

In This Part

CHAPTER 19 Windows Server 2003 Administration

CHAPTER 20 Windows Server 2003 System Registry

CHAPTER 21 Windows Server 2003 Group Policies

CHAPTER 22 Windows Server 2003 Management and Maintenance Practices

CHAPTER 23 Automating Tasks Using Windows Server 2003 Scripting

CHAPTER 24 Documenting a Windows Server 2003 Environment

CHAPTER 25 Integrating Microsoft Operations Manager with Windows Server 2003


Chapter 19. Windows Server 2003 Administration

In This Chapter

  • Defining the Administrative Model

  • Examining Active Directory Site Administration

  • Configuring Sites

  • Examining Windows Server 2003 Active Directory Groups

  • Creating Groups

  • Handling User Administration

  • Understanding User Profiles

  • Managing Users with Local Security and Group Policies

  • Managing Printers with Print Management Component

Administrators can administer a Windows Server 2003 infrastructure by learning only a few simple tasks and applying them at different levels and to different objects. The overall management of an environment is composed of administrative tasks that touch almost every aspect of the network, including user administration, server and workstation administration, and network administration. For example, in a single day an administrator might check for a successful server backup, reset a user's password, add users to or remove them from existing groups, or manage LAN and WAN hardware. Although each of these tasks can independently be very simple or difficult in nature, administrators should at least understand their portion of the overall enterprise network and understand how the different components that make up the network communicate and rely on one another.

This chapter focuses on the common Windows Server 2003 Active Directory (AD) user and group administrative tasks and touches on the management of Active Directory sites to optimize user access and replication performance.


Defining the Administrative Model

Before the computer and networking environment can be managed effectively, an organization and its IT group must first define how the tasks will be assigned and managed. The job of delegating responsibility for the network defines the organization's administrative model. Three different types of administrative modelscentralized, distributed, and mixedcan be used to logically break up the management of the enterprise network between several IT specialists or departments within the organization's IT division. When there is no administrative model, the environment is managed chaotically, and the bulk of work is usually made up of fire-fighting. Server updates and modifications must more frequently be performed on the spot without proper testing. Also, when administrative or maintenance tasks are not performed correctly or consistently, securing the environment and auditing administrative events are nearly impossible. Environments that do not follow an administrative model are administered reactively rather than proactively.

To choose or define the correct administrative model, the organization must discover what services are needed in each location and where the administrators with the skills to manage these services are located. Placing administrators in remote offices that require very little IT administration might be a waste of money, but when the small group is composed of VIPs in the company, it might be a good idea to give these elite users the highest level of service available.

The Centralized Administration Model

The centralized administration model is simple in concept: All the IT-related administration is controlled by one group, usually located at one physical location. In the centralized model, all the critical servers are housed in one or a few locations instead of distributed at each location. This arrangement allows for a central backup and always having the correct IT staff member available when a server fails. For example, if an organization uses the Microsoft Exchange 2003 messaging server and a server is located at each site, a qualified staff member might not be available at each location if data or the entire server must be recovered from backup. In such a scenario, administration would need to be handled remotely if possible, but in a centralized administration model, both the Exchange Server 2003 administrator and the servers would be located in the same location, enabling recovery and administration to be handled as efficiently and effectively as possible.

The Distributed Administration Model

The distributed administration model is the opposite of the centralized model in that tasks can be divided among IT and non-IT staff members in various locations. The rights to perform administrative tasks can be granted based on geography, department, or job function. Also, administrative control can be granted for a specific network service such as DNS or DHCP. This allows separation of server and workstation administration without giving unqualified administrators the rights to modify network settings or security.

Windows Server 2003 systems allow for granular administrative rights and permissions, giving enterprise administrators more flexibility when assigning tasks to staff members. Distributed administration based only on geographical proximity is commonly found among organizations. After all, if a physical visit to the server, workstation, or network device is needed, having the closest qualified administrator responsible for it might prove more effective.

The Mixed Administration Model

The mixed administration model is a mix of administrative responsibilities, using both centralized and distributed administration. One example could be that all security policies and standard server configurations are defined from a central site or headquarters, but the implementation and management of servers are defined by physical location, limiting administrators from changing configurations on servers in other locations. Also, the rights to manage only specified user accounts can be granted to provide even more distributed administration on a per-site or per-department basis.


Examining Active Directory Site Administration

Sites can be different things, depending on whom you ask. Within the scope of Active Directory, a site defines the internal and external replication boundaries and helps users locate the closest servers for authentication and network resource access. If you ask an operations manager, she might describe a site as any physical location from which the organization operates business. This section discusses Active Directory site administration.

AD sites can be configured to match a single or many locations that have high-bandwidth connectivity between them. They can be optimized for replication and, during regular daily operations, require very little network bandwidth. After an AD site is defined, servers and client workstations use the information stored in the site configuration to locate the closest domain controllers, global catalog servers, and distributed file shares. Configuring a site can be a simple task, but if the site topology is not defined correctly, network access speed might suffer because servers and users may connect to resources across the wide area network instead of using local resources. In most cases, defining and setting up an Active Directory site configuration might take only a few hours of work. After initial setup, AD sites rarely need to be modified unless changes are made to network addressing, domain controllers are added to or removed from a site, or new sites are added and old ones are decommissioned.

Site Components

As mentioned previously, configuring a site should take only a short time because there are very few components to manipulate. A site is made up of a site name; subnets within that site; links and bridges to other sites; site-based policies; and, of course, the servers, workstations, and services provided within that site. Some of the components, such as the servers and workstations, are dynamically configured to a site based on their network configuration. Domain controller services and Distributed File System (DFS) targets are also located within sites by the network configuration of the server on which the resources are hosted.

Subnets

Subnets define the network boundaries of a site and limit WAN traffic by allowing clients to find local services before searching across a WAN link. Many administrators do not define subnets for locations that do not have local servers; instead, they relate site subnets only to Active Directory domain controller replication. If a user workstation subnet is not defined within Active Directory, the user workstation may authenticate and download policies or run services from a domain controller that is not directly connected to a local area network. This authentication and download across a WAN could create excessive traffic and unacceptable response times.

Site Links

Site links control Active Directory replication and connect individual sites directly together. A site link is configured for a particular type of protocolnamely, RPC, IP, or SMTPand the frequency and schedule of replication is configured within the link.

Licensing Server (Per Site)

Within Active Directory, server licenses and licensing usage can be tracked by a central server in each site. Using the Active Directory Sites and Services Microsoft Management Console (MMC) snap-in, you can define a particular server as the site-licensing server. All Windows servers, including NT4, Windows 2000, and Windows Server 2003, replicate licenses and licensing usage to this server. The site-licensing servers replicate with one another to enable the enterprise administrator to track licenses for the entire enterprise from the Licensing console on any of the site-licensing servers.

Site Group Policies

Site group policies allow computer and user configurations and permissions to be defined in one location and applied to all the computers and/or users within the site. Because the scope of a site can span all the domains and domain controllers in a forest, site policies should be used with caution. Therefore, site policies are not commonly used except to define custom network security settings for sites with higher requirements or to delegate administrative rights when administration is performed on a mostly geographic basis.

Note

Because sites are usually defined according to high-bandwidth connectivity, some design best practices should be followed when you're defining the requirements for a site. If possible, sites should contain local network services such as domain controllers, global catalog servers, DNS servers, DHCP servers, and, if necessary, WINS servers. This way, if network connectivity between sites is disrupted, the local site network will remain functional for authentication, Group Policy, name resolution, and resource lookup. Placing file servers at each site may also make sense unless files are housed centrally for security or backup considerations.


Configuring Sites

The job of configuring and creating sites belongs to the administrators who manage Active Directory, but those who manage the network must be well informed and possibly involved in the design. Whether Active Directory and the network are handled by the same or different groups, they affect each other, and undesired network utilization or failed network connectivity may result. For example, if the Active Directory administrator defines the entire enterprise as a single site and several Active Directory changes happen each day, replication connections would exist across the enterprise, and replication traffic might be heavy, causing poor network performance for other networking services. On the other side, if the network administrator allows only specific ports to communicate between certain subnets, adding Active Directory might require that additional ports be opened or involve specific network requirements on the servers at each location.

Creating a Site

When creating a site, Active Directory and network administrators must decide how often AD will replicate between sites. They also must share certain information such as the line speed between the sites and the IP addresses of the servers that will be replicating. Knowing the line speed helps determine the correct cost of a site link. For the network administrator, knowing which IP addresses to expect network traffic from on certain ports is helpful when troubleshooting or monitoring the network. To create a site, the AD administrator needs a site name and subnet and also needs to know which other sites will replicate to the new site.

To create a site, follow these steps:

1.
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.

2.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.

3.
Choose Start, Run. Type MMC.exe and click OK.

4.
Choose File, Add/Remove Snap-in.

5.
Click Add in the Add/Remove Snap-in window.

6.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.

7.
In the console window, click the plus sign next to Active Directory Sites and Services.

8.
Right-click the Sites container and choose New Site.

9.
Type in the name of the site and select any existing site link, as shown in Figure 19.1. Then click OK to create the site.

Figure 19.1. Creating a new site.

10.
A pop-up window might appear, stating what tasks still need to be completed to properly create a site. Read the information, take notes if necessary, and click OK.

Creating Site Subnets

After you create a site, it should be listed in the console window. To complete the site creation process, follow these steps:

1. | Within the console window, right-click the Subnets container and choose New Subnet.
2. | Type in the address of the subnet and subnet mask, select the appropriate site from the list at the bottom of the window, and click OK to create the new subnet and associate it with the new site. If you are not sure about the address to enter, just enter the IP address and subnet mask of a device on that network, and the wizard will select the correct network number for you.
Adding Domain Controllers to Sites

If a new domain controller is added to a forest, it will dynamically join a site with a matching subnet if the site topology is already configured and subnets have been previously defined. If an existing domain controller is being moved to a new site or the site topology or replication strategy has changed, you can follow these steps to move a domain controller to a different site:

1.
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.

2.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.

3.
Choose Start, Run. Then type MMC.exe and click OK.

4.
Choose File, Add/Remove Snap-in.

5.
Click Add in the Add/Remove Snap-in window.

6.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.

7.
In the console window, click the plus sign next to Active Directory Sites and Services.

8.
Locate the site that contains the desired domain controller. You can browse the site servers by expanding the Sites container, expanding a site within it, and selecting the Servers container of the site, as shown in Figure 19.2.

Figure 19.2. Browsing site servers.

[View full size image]

9.
When you locate the desired server, take note of the source site, right-click the server name, and choose Move.

10.
When a window opens listing all the sites in the forest, select the destination site and click OK to initiate the server move.

11.
When the move is complete, verify that the domain controller has been placed in the correct Servers container of the desired site.

If necessary, manually create replication connections if the desired connections are not automatically created by the Inter-Site Topology Generator (ISTG) within 15 minutes after moving the server. For information on the ISTG and replication connections, refer to Chapter 7, "Active Directory Infrastructure."

Configuring Licensing for the Enterprise

Within Active Directory, server licensing is replicated to a designated site-licensing server. Each site-licensing server replicates its licensing information to the licensing servers in other sites so that each server has the enterprise licensing information. Licensing replication follows the replication interval set on the individual server from within the Licensing applet in the Control Panel of each server. The first domain controller in a site becomes the site-licensing server.

To change the site-licensing server, follow these steps:

1.
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.

2.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.

3.
Choose Start, Run. Then type MMC.exe and click OK.

4.
Choose File, Add/Remove Snap-in.

5.
Click Add in the Add/Remove Snap-in window.

6.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.

7.
In the console window, click the plus sign next to Active Directory Sites and Services.

8.
Select the desired site in the left pane. Then, in the right pane, right-click Licensing Site Settings and choose Properties, as shown in Figure 19.3.

Figure 19.3. Opening the Licensing Site Settings properties page.

[View full size image]

9.
Within the Licensing Site Settings property page, note the licensing computer at the bottom of the window and, if desired, click the Change button to specify a computer.

10.
In the Select Computer window, type in the name of the desired domain controller and click OK.

11.
Back on the Licensing Site Settings property page, click OK to change the licensing server for the site.

Configuring Server/Workstation Licensing Options

To get proper licensing usage information for the entire enterprise, the administrator must understand how licensing information is replicated. Each server replicates its licensing information to the site-licensing server based on a replication interval set in the Licensing applet located in the Control Panel within the server console. The default is set to 24 hours, so licensing information is replicated to the site-licensing server once a day.

Adding Licenses

When per-user or per-device client access licenses need to be added to properly track Windows and possibly BackOffice, Exchange, and SMS licenses, the licenses should be added directly on the site-licensing server. This ensures that the licenses show up on the licensing server immediately. Many administrators do not understand licensing, so they either disable the licensing logging service or add licenses several times until they realize that the added licenses show up on the licensing server only after replication.

Establishing Site Links

Site links establish connectivity between domain controllers to allow Active Directory replication to be managed and scheduled. The Active Directory database, global catalog, Group Policies, and domain controller SYSVOL share replicate according to the replication schedule configured in a site link. For more information on site links, refer to Chapter 7.

To create an IP-based site link, follow these steps:

1.
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.

2.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.

3.
Choose Start, Run. Type MMC.exe and click OK.

4.
Choose File, Add/Remove Snap-in.

5.
Click Add in the Add/Remove Snap-in window.

6.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.

7.
In the console window, click the plus sign next to Active Directory Sites and Services.

8.
Expand the Sites container and double-click the Inter-Site Transports container.

9.
Right-click the IP container and select New Site Link.

10.
Enter a name for the site link, select a site that will replicate Active Directory using this site link, and click Add. Repeat this step until all the desired sites are in the right window, as shown in Figure 19.4.

Figure 19.4. Adding sites to a site link.

[View full size image]

11.
Click OK to create the site link.

12.
Back in the Active Directory Sites and Services console, right-click the new site link in the right pane and choose Properties.

13.
At the top of the window, enter a description for the site link. For example, enter Site link between site A and site B. Keep the description simple but informative.

14.
At the bottom of the window, enter a cost for the site link and enter the replication frequency. This number indicates how often Active Directory will attempt to replicate during the allowed replication schedule.

15.
Click the Change Schedule button to configure specific intervals when Active Directory should not replicate and click OK.

16.
Click OK in the Site Link property page to complete the site link configuration.

After the site link is configured, the Active Directory connections between domain controllers in different sites may generate new connections to optimize replication.

Delegating Control at the Site Level

Control is sometimes delegated at the site level to give network administrators the rights to manage Active Directory replication without giving them the rights to manage any additional Active Directory objects. Site delegation can also do just the opposite, effectively denying network administrators the right to access Active Directory objects on a per-site basis. Specific administrative rights can be granted using the built-in Delegate Control Wizard, whereas others can be set for all the site objects using a site's Group Policies.

To delegate control at the site level, follow these steps:

1. | Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.
2. | Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.
3. | Choose Start, Run. Type MMC.exe and click OK.
4. | Choose File, Add/Remove Snap-in.
5. | Click Add in the Add/Remove Snap-in window.
6. | Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.
7. | In the console window, click the plus sign next to Active Directory Sites and Services.
8. | Right-click the Sites container and select Delegate Control.
9. | Click Next on the Delegate Control Wizard Welcome screen.
10. | Using the Add button, select the user, users, or groups that will delegate control over the site and click Next to continue. You may choose an Active Directory group created for the organization's networking team or the default group named Network Configuration Operators.
11. | In the Active Directory Object Type page, select This Folder, Existing Objects in This Folder and Creation of New Objects in This Folder, which is the default option to delegate control, and then click Next. The permissions granted will trickle down to each of the containers below the initial Sites container. If you don't want this outcome, return to step 8 and select the appropriate site or subnet container.
12. | On the Permissions page, check the desired permissions type boxes and choose each permission the administrator or, in this case, the networking group should have.
13. | Click Next and then Finish to complete the Delegate Control Wizard.


Examining Windows Server 2003 Active Directory Groups

An Active Directory group is made up of a collection of objects (users and computers and other groups used to simplify resource access and for emailing purposes). Groups can be used for granting administrative rights, granting access to network resources, or distributing email. There are many flavors of groups, and depending on which mode the domain is running in, certain group functionality might not be available.

Group Types

Windows Server 2003 Active Directory supports two distinct types of groups: distribution and security. Both have their own particular uses and advantages if they are used properly and their characteristics are understood.

Distribution Groups

Distribution groups allow for the grouping of contacts, users, or groups primarily for emailing purposes. These types of groups cannot be used for granting or denying access to domain-based resources. Discretionary Access Control Lists (DACLs), which are used to grant or deny access to resources or define user rights, are made up of Access Control Entries (ACEs). Distribution groups are not security enabled and cannot be used within a DACL. In some cases, this might simplify security management when outside vendors need to be located in address books but will never need access to resources in the domain or forest.

Security Groups

Security groups are security enabled and can be used for assigning user rights and resource permissions or for applying computer and Active Directorybased Group Policies. Using a security group instead of individual users simplifies administration. Groups can be created for particular resources or tasks, and when changes are made to the list of users who require access, only the group membership must be modified to reflect the changes throughout each resource that uses this group.

To perform administrative tasks, security groups can be defined for different levels of responsibility. For example, a level 1 server administrator may have the right to reset user passwords and manage workstations, whereas a level 2 administrator may have those permissions plus the right to add or remove objects from a particular organizational unit or domain. The level of granularity granted is immense, so creating a functional security group structure can be one way to simplify administration across the enterprise. Security groups can also be used for emailing purposes, so they can serve a dual purpose.

Group Scopes in Active Directory

To complicate the group issue somewhat more, after the type of group is determined, the scope of the group must also be chosen. The scope, simply put, defines the boundaries of who can be a member of the group and where the group can be used. Because only security groups can be used to delegate control or grant resource access, security group types are implied for the rest of this chapter.

Domain Local Groups

Domain local groups can be used to assign permissions to perform domain-based administrative tasks and to access resources hosted on domain controllers. These groups can contain members from any domain in the forest and can also contain other groups as members. Domain local groups can be assigned permissions only in the domain in which they are hosted.

Global Groups

Global groups are somewhat more functional than domain local groups. These groups can contain members only from the domain in which they are hosted, but they can be assigned permissions to resources or delegated control to perform administrative tasks or manage services across multiple domains when the proper domain trusts are in place.

Universal Groups

Universal groups can contain users, groups, contacts, or computers from any domain in the forest. This simplifies the need to have single-domain groups that have members in multiple forests. Universal group memberships should be kept low or should not be changed frequently because group membership is replicated across domains and populated in the global catalog. As a best practice, create a universal group to span domains but have only a global group from each domain as a member. This practice reduces cross-domain replication.

Note

Universal security groups can be created only in domains running in Windows 2000 Native or Windows Server 2003 domain functionality level. If this level cannot be reached, use global groups from each domain when setting permissions on resources that need to be accessed from users in many domains.


Creating Groups

When it comes to creating groups, understanding the characteristics and limitations of each different type and scope is only half the battle. Other points to consider for group creation are how the group will be used and who will need to be a member of the group. A group is commonly used for three separate functions, including delegating administrative rights, distributing email, and securing network resources such as file shares and printer devices. To help clarify group usage, the following examples show how the different groups can be used in different administrative scenarios.

User Administration in a Single Domain

If a group is needed to simplify the process of granting rights to reset user passwords in a single domain, either a domain local or global security group would suffice. The actual domain user rights should have local groups applied only to their access control lists or settings, but these local groups should have global groups as members. For a single-domain model, if the specific user rights need to be granted only at the domain level, a domain local group with users as members would be fine. However, if you need to add the same group of users to an access control list on a member server resource or you need to create a completely new domain, the domain local group cannot be used. This is the main reason it is recommended to place users only into global groups and assign permissions to resources using local groups that have global groups as members. After you use this strategy and use global groups over and over, saving administration time, the reasoning will be validated.

User Administration Across a Forest of Domains

When multiple domains need to be supported by the same IT staff, even if the domain levels are set to Windows 2000 Mixed mode, each domain's Domain Admins group should be added to each domain's Administrators group. For example, domain A's Administrators group would have Domain A Domain Admins, Domain B Domain Admins, and Domain C Domain Admins groups as members. You would need to add these domains whenever a resource or administrative task needs to grant or deny groups from each domain access to a resource in the forest.

If all the domains in the forest run in Windows 2000 Native or Windows Server 2003 Native Domain functional level, you could create a Universal security group named Forest Admins with each of the domain's Domain Admin groups as members. Then you would need to configure only a single entry to allow all the administrators access forest-wide for a particular resource or user right. Universal security groups are useful because they can have members from each domain, but if a proper group strategy has been developed, domain local and domain global groups could still handle most situations.

Domain Functionality Level and Groups

There are many different domain functionality levels, with each level adding more functionality. The reason for all the different levels is to provide backward compatibility to support domain controllers running on different platforms. This allows a phased migration of the domain controllers. The four main domain functionality levels are

  • Windows 2000 Mixed This domain level mode was created primarily to allow both Windows 2000 and Windows NT 4.0 domain controllers to function in an Active Directory domain. Universal security groups and any group nesting other than nesting global groups into local groups are not options. This level can be raised to Windows 2000 Native or Windows Server 2003 Native after all the domain controllers are upgraded to the necessary operating system levels.

  • Windows 2000 Native This domain level allows only Windows 2000 and Windows Server 2003 domain controllers in the domain. Universal security groups can be leveraged, along with universal and global security group nesting. This level can be raised to Windows Server 2003 Native level. This mode also allows you to change some existing groups' scope and type on the fly.

  • Windows Server 2003 Native This level allows only Windows Server 2003 domain controllers and provides all the features of the Windows 2000 Native domain level, plus additional security and functionality features such as domain rename.

  • Windows Server 2003 Interim Windows Server 2003 Interim mode enables the Windows Server 2003 Active Directory to interoperate with a domain composed of Windows NT 4.0 domain controllers and Windows Server 2003 domain controllers only. This level was created to support environments that seek to upgrade directly from NT 4.0 to Windows Server 2003 Active Directory. This domain level can be raised only to Windows Server 2003 Native domain level. This mode is listed only if an NT 4.0 domain PDC has been upgraded to a Windows Server 2003 domain controller.

Creating AD Groups

Now that you understand what kinds of groups you can create and what they can be used for, you are ready to create a group. To do so, follow these steps:

1.
Log on to a domain controller using an account with the rights to create groups in the respective domain. Usually, an account with Domain Admin rights will suffice.

2.
Choose Start, All Programs, Administrative Tools, Active Directory Users and Computers.

3.
Select a container in the left pane; for example, the Users container. Right-click it and select New, Group.

4.
Enter the group name and select the appropriate group type and scope, as shown in Figure 19.5. Click OK to finish creating the group.

Figure 19.5. Creating a group.

Populating Groups

After you create a group, you can add members to it. The domain level that the domain is running in will determine whether this group can have other groups as members.

To add members to an existing group, follow these steps:

1. | Log on to a domain controller using an account with the rights to create groups in the respective domain. Usually, an account with Domain Admin rights will suffice.
2. | Choose Start, All Programs, Administrative Tools, Active Directory Users and Computers.
3. | Select the container that contains the group you want in the left pane. Then, in the right pane, right-click the group and select Properties.
4. | Enter a description for the group on the General tab and then click the Members tab.
5. | Click Add to add members to the group.
6. | In the Select Users, Contacts, Computers or Groups window, type in the name of each group member separated by a semicolon and click OK to add these users to the group. If you don't know the names, clicking the Advanced button opens a window where you can perform a search to locate the desired members.
7. | When all the members are listed on the Members tab of the group's property page, click OK to complete the operation.

Group Management

After a group is created, it needs to be managed by an administrator, users, or a combination of both, depending on the dynamics of the group. For example, when Exchange Server 2003 is being leveraged in an Active Directory environment, administrative assistants commonly need to modify certain mailing group memberships. For this particular example, if the proper permissions on the group are defined, an administrative assistant would be able to manage group membership using her Outlook client. If group membership needed to be managed outside Outlook, the administrative assistant would need the Windows Server 2003 Administration Pack installed on the workstation.

To delegate control of a group to a particular user, follow these steps:

1.
Log on to a domain controller with Domain Administrator privileges.

2.
Choose Start, All Programs, Administrative Tools, Active Directory Users and Computers.

3.
Select the container that contains the group you want in the left pane. Then, in the right pane, right-click the group and select Properties.

4.
Select the Security tab. If the Security tab is not visible, close the group, and in the Active Directory Users and Computers MMC snap-in, select View, Advanced Features. Open the properties of the desired group and select the Security tab afterward.

5.
On the bottom of the page, click the Advanced button.

6.
In the Advanced Security Settings for Group page, select the Permissions tab.

7.
Click Add. In the Select User, Computer or Group window, type in the name of the account for which you want to grant permissions and click OK.

8.
When the Permissions Entry for Group window appears, select the Properties tab.

9.
Select Apply Onto, Group Objects.

10.
In the Permissions section, check the Allow boxes for Read Members and Write Members, as shown in Figure 19.6. Then click OK.

Figure 19.6. Granting permissions to modify group membership.

11.
Click OK to close the Advanced Security Settings for Group page.

12.
Click OK to close the group's property pages. Then click File, Exit, No (to save console settings) to close the Active Directory Users and Computers MMC snap-in, and log out of the server.


Handling User Administration

So far this chapter has covered site and group administration, which for the most part require little daily administration. Unfortunately, this is not the case for user administration. With user administration comes several repetitive tasksfor example, changing or adding attribute values such as phone number, resetting passwords for locked-out accounts, managing user profiles, and changing user group membership and user desktop support. These tasks generally are not planned but have to be addressed on a daily basis.

With user administration also comes periodic tasks that must be run to optimize and keep the environment as secure as possiblefor example, running reports for inactive or disabled accounts, updating login scripts, and updating user profiles.


Understanding User Profiles

A user profile is made of up of all the settings used to configure a user's desktop experience. Elements stored in a user's profile are Internet Explorer favorites, mapped drive and printer configurations, email profiles, My Documents folder data, application-specific configurations or settings, desktop settings, and much more. Administrators frequently need to update or reconfigure a user's profile when a configuration change is necessary or if a new profile is being created.

Examining Profile Types

Several types of user profiles are available, giving administrators greater flexibility when it comes to customizing and automating profile settings. Although each profile type described in the following sections offers certain features, many profile settings can also be configured using Group Policy.

Local Profile

A local user profile is stored on the local server or workstation's hard disk. This type of profile is maintained and used only on a single machine. If this profile is lost or the user moves to a new machine, a new profile must be created and configured manually. Local profiles are always stored on the local machine, regardless of whether the user is logging on with a roaming or mandatory profile.

Roaming Profile

A roaming profile is stored on a server file share and follows a user to whatever server or workstation he logs in to. Upon logon, the roaming profile is downloaded from the server share to the local machine. The user then runs the profile from the local cached copy of the roaming profile throughout the entire session. Upon logoff, the profile is saved back to the server share location with any updates intact.

Because roaming profiles must be copied down from the server during logon and pushed back to the server upon logoff, this process can extend user logon/logoff intervals. The bigger the profile size, the longer the wait. Here's an example. One of our former clients complained that certain users required 15 minutes to log on and 15 minutes to log off. Upon investigation, we found out that these users had more than 400MB of temporary Internet files and the client was on a 10MB network. To fix this problem, we created a Group Policy setting, and configured Internet Explorer to delete all temporary Internet files upon exiting. This reduced the overall profile size and immediately improved logon/logoff performance.

Other folders to consider when planning to use roaming profiles are the My Documents and Desktop folders. Either advise your users to save data directly to their home network drive, or redirect both the Desktop and My Documents folders to a server to eliminate the need for the data stored within these folders to be uploaded and downloaded with the profile during logon/logoff.

Mandatory Profile

A mandatory profile is the same as a roaming profile except that changes made to the profile settings are not saved to the server upon logoff. This type of profile is most commonly used in classroom environments in educational institutions or for public shared access workstations such as those found in an Internet cafe. To change a profile to a mandatory profile, configure the profile as you like and log out of that user account. Then, with an Administrator account, locate the profile folder and rename the Ntuser.dat file to Ntuser.man.

Default User Profile

On each Windows 2000 and Windows XP system that was not upgraded from a previous version of the operating system, a default profile folder exists. This profile is used when a user logs on to the system for the first time and her account is not configured to download a roaming or mandatory profile. To create a common profile for all new users when they log on, configure a profile using a test user account and save this profile to the default profile folder.

Temporary Profile

A temporary profile is used when a user with a roaming profile cannot locate the profile folder on the server. When this happens, the machine first attempts to load this user's profile from a cached copy on the local profile. This profile might be outdated but will most likely have all the correct information. If a user has never logged on to the workstation but specifies a roaming profile that cannot be located or does not exist yet, the temporary profile will become that user's profile and be saved up to the server upon logoff, if possible. In other words, if no local copy of the profile exists, the temporary profile is built from the default profile folder.

All Users Profile

The All Users profile folder houses profile settings that you want to apply to all users logging on to the system. The settings, usually desktop and Start menu customizations, are added to the user's existing profile. The All Users profile additions are not carried over or saved to the roaming or local profile. These settings are machine specific only.

Template Profiles

When new users are added to an organization, their profiles need to be created from scratch or possibly from a custom script that leverages resource kit tools to minimize the tasks necessary to configure the profiles. To simplify this process even more, you could create template profile folders and save them to a server location. When a new user is created, this profile can be copied to the desired profile location and can be used as a profile starting point for that user. The process to create a template profile is the same as creating a default profile, outlined in the next section, but the location where the profile is saved may vary.

Creating a Default Profile

You can create a default profile by logging on to a workstation and manually configuring the desktop settings as desired, including network shortcuts, desktop shortcuts, printers, mapped drives, environmental settings such as path temp file location, and Internet settings. Most of these tasks can also be performed using Group Policy and logon scripts, but configuring a default profile ensures that the desired settings are delivered to each user regardless of whether the user is a local or domain user or if the policy is applied correctly.

To create a default profile, follow these steps:

1. | Log on to a workstation with a standard local or domain user account, with the same level of access a standard user will have. For this example, use an account called TemplateUser1.
2. | Configure the profile the way you want it. Create desktop settings, Internet settings, or whatever is necessary for a standard user.
3. | Log off the workstation. The profile is then saved to the c:\Documents and Settings\TemplateUser1 directory.

Copying Profiles for the Default User Profile

To make a profile the default profile, you must copy the files to the default user profile folder. To copy the profile, perform the following steps:

1.
Log in with an Administrator account.

2.
Choose Start, Control Panel.

3.
Double-click the System applet.

4.
Select the Advanced tab and click the Settings button in the User Profiles section.

5.
Select the correct profile, as shown in Figure 19.7, and click the Copy To button.

Figure 19.7. Selecting the profile to copy.

6.
In the Copy To window, enter the path to the default user directory. If necessary, click Browse and find the correct folder. The default location is C:\Documents and Settings\Default User.

7.
You don't need to change the Permitted to Use section, so click OK to complete this task.


Managing Users with Local Security and Group Policies

Windows Server 2003 systems provide local security policies to manage user and group administrative access on a per-server basis. Within Active Directory, you can use group policies to set configurations and security on a specified collection of computers, users, or groups of users from a single policy. These policies can be used to deliver standard desktop configurations and security settings for server access and application functionality. Also, policies can set user configurations to deliver software on demand, redirect desktop folders, plus affect many more settings. Many settings within each policy explain what the setting controls and whether computer-based settings apply to only Windows XP workstations. Chapter 15, "Security Policies and Tools," describes security policy in more depth, but the best way to discover and learn about all the Group Policy settings is to open an actual Group Policy Object and start browsing each section.

Viewing Policies with the Group Policy Object Editor

You can view Active Directorybased group policies or server and workstation local security policies with very little effort by using a single console. Using the Group Policy Object Editor MMC snap-in, you can read and configure both Group Policy Objects and local security policies.

To open an existing policy, follow these steps:

1.
Log on to a Windows Server 2003 system or an XP workstation with the Administration Pack installed.

2.
Choose Start, Run. Type MMC.exe and click OK.

3.
If you used a standard user account to log on, at the Run prompt, type runas/user:administrator mmc.exe and click OK to open the MMC with an elevated account. In this example, you use the Administrator account, but you can use any account with the rights to view or modify the respective policy.

4.
A command-prompt window then opens, prompting for the correct password if you used the runas command. Type in the password and press Enter.

5.
When the MMC opens, choose File, Add/Remove Snap-in.

6.
In the Add/Remove Snap-in window, click Add.

7.
In the Add Stand-alone Snap-in page, scroll down and select Group Policy Object Editor and then click Add.

8.
The Select Group Policy Wizard opens, asking which policy you want to open. The default is the local computer policy of the machine currently logged in. To choose a domain-based group policy or a local security policy on a different server workstation, click the Browse button.

9.
Select the correct tab to find the policy, as shown in Figure 19.8, and click OK.

Figure 19.8. Selecting the desired policy to view or manage.

10.
Click Finish in the Select Group Policy Wizard, click Close in the Add Stand-alone Snap-in page, and click OK in the Add/Remove Snap-in window to return to the console and access the respective policy.

After you access the policy, you can view each setting or settings container to determine the default value and, in some cases, learn what the setting controls. Keep in mind that, with the correct level of permissions, any changes you make to this policy are live changes; there is no undo other than reversing the individual setting changes or performing a Primary restore of the SYSVOL folder on a domain controller that has already replicated the changes.

Creating New Group Policies

When changes need to be made or tested using group policies, the administrator should leave the production environment untouched and create test policies in isolated test lab environments. When test labs are not available or cannot replicate the production environment, the administrator can test policies in isolated organizational units within a domain. Also, if domain- or site-based policies need to be created for testing, security filtering could be modified to apply the policy only to a specific set of test users or groups.

The preceding section described how to locate a group policy. Using the Active Directory Users and Computers and Active Directory Site and Services snap-ins, you can create, configure, and open site, domain, and organizational unit (OU) group policies for editing. The following steps outline how to create a new domain-based policy and configure its security filtering to apply to a single user:

1. | Log on to a Windows Server 2003 system or an XP workstation with the Windows Server 2003 Administration Pack installed.
2. | Choose Start, Run. Type MMC.exe and click OK.
3. | If you used a standard user account to log on, at the Run prompt, type runas/user:administrator mmc.exe and click OK to open the MMC with an elevated account. In this example, you use the Administrator account, but you can use any account with the rights to view or modify the respective policy.
4. | A command-prompt window then opens, prompting for the correct password if you used the runas command. Type in the password and press Enter.
5. | When the MMC opens, choose File, Add/Remove Snap-in.
6. | In the Add/Remove Snap-in window, click Add.
7. | In the Add Stand-alone Snap-in page, select Active Directory Users and Computers and click Add.
8. | Click Close in the Add Stand-alone Snap-in page and click OK in the Add/Remove Snap-in window to return to the console and access the snap-in.
9. | The snap-in defaults to the domain used for the login. To change the domain focus, right-click Active Directory Users and Computers in the left pane and select Connect to Domain.
10. | Type in the fully qualified name of the domain and click OK to return to the console. If necessary, click the Browse button to locate the domain.
11. | In the console, you should see the domain listed. Right-click the domain listing and select Properties.
12. | Select the Group Policy tab and then click the New button. A new policy then appears in the window.
13. | Type in a descriptive policy name and press Enter to create the policy.
14. | When the policy is listed, select it and click the Properties button.
15. | Select the Security tab and highlight the Authenticated Users entry.
16. | In the Permissions section, scroll down and uncheck the Allow box for Apply Group Policy.
17. | Select each entry in the Group Policy access control list and verify that no existing groups are allowed to apply the group policy.
18. | Click Add and type in the name of a user or group. To find a list of users and groups within the current domain, click the Advanced button, and in the search window, click Find Now to return the complete list. Scroll down and select the users or groups you want and click OK.
19. | Click OK to add the entries to the policy.
20. | Back in the security window, select the respective entry and check the Allow box for Apply Group Policy, as shown in Figure 19.9. Click OK when you're finished.
21. | Click Apply to update the Group Policy security; then select the General tab.
22. | On the bottom of the General tab, you can disable the Computer or User Settings section of Group Policy to improve policy application intervals. Leave both sections enabled if both user and computer settings will be used. Click OK to close the Group Policy properties.
23. | If you want to configure the group policy now, select the policy from the window and click the Edit button to open the Group Policy Object Editor with the focus on the new policy. Otherwise, click Close.

Configuring and Optimizing Group Policy

After a Group Policy Object is created, a few steps should be taken to configure how the policy will be applied and to optimize the time to apply the policy. Group policies can be limited to computer- or user-specific settings. To determine whether either type of setting can be disabled, the administrator should figure out which settings are necessary to provide the desired policy settings. In many cases, a policy uses settings for both types. To disable either user or computer policy settings, open the properties as described in the section "Viewing Policies with the Group Policy Object Editor" earlier in this chapter. When the policy is listed, right-click the policy and select Properties. On the General tab, check the appropriate boxes to disable computer or user settings and click OK to save the settings.

Figure 19.9. Modifying a group policy's application scope.

When multiple group policies exist, they are applied in a predefined order. For a particular user or computer, the order can be derived using the Resultant Set of Polices snap-in described in the "The Resultant Set of Policies MMC Snap-in" section. The results of standard policies are that if setting X is enabled on a top-level policy and disabled on the last policy to apply to an object, the resulting setting will disable setting X. Many policy settings have three states: enabled, disabled, and the default of not configured.

You can limit group policies to apply to specific users or computers by modifying the security entries. They can be limited to which types of settings will be disabled using the general properties of the policy, and policies can be blocked at the site, domain, or OU container level using a setting called Block Policy Inheritance. When company-wide, domain-wide, or site-wide settings need to be configured and imposed, the group policy can be configured to use No Override.

Block Policy Inheritance

The Block Policy Inheritance option allows an administrator to prevent higher-level policies from applying to users and computers within a certain site, domain, or OU. This capability can be useful to optimize Group Policy applications and to ensure that rights are grandfathered down to the Active Directory objects within the container.

To block policy inheritance, follow these steps:

1.
To block inheritance, open either the AD Users and Computers MMC snap-in for domain or OU objects or the AD Sites and Services MMC snap-in for site objects.

2.
Right-click the object you want to modify and select Properties.

3.
Select the Group Policy tab and check the Block Policy Inheritance box, as shown in Figure 19.10.

Figure 19.10. Blocking policy inheritance for an OU.

4.
Click OK to update the container's Group Policy properties.

The No Override Options

Configuring the No Override option prevents lower-level policies from blocking policy inheritance and from changing the parameters or configured settings in a policy. This option should be used only if policy needs to be enforced on AD objects in every container and subcontainer with a link or inheritance to this policy object.

To configure the No Override option for the default domain policy, follow these steps:

1. | Open the AD Users and Computers MMC snap-in for the desired domain.
2. | Right-click the domain listing and select Properties.
3. | Select the Group Policy tab, select the default domain, and click the Options button.
4. | Check the No Override box and click OK in the Policy Options property page.
5. | Click OK to close the Domain property page to complete the process.

Troubleshooting Group Policy Applications

When policies are used throughout an organization, sometimes the policy settings do not apply to a user or computer as originally intended. To begin basic troubleshooting of Group Policy application issues, you need to understand the policy application hierarchy. First, the local server or workstation policy applies to the user or computer, followed by site group policies, domain group policies, and finally the organizational unit group policies. If nested OUs have group policies, the parent OU policies are processed first, followed by the child OUs, and finally the OU containing the Active Directory object (user or computer). You might find it easier to remember "LSD-OU"the acronym for local, site, domain, and then OU.

Now that you know the order in which policies are applied, you can proceed to use the Group Policy testing and troubleshooting tools provided with Windows Server 2003namely the Resultant Set of Policies MMC snap-in and the command-line utility GPResult.exe, which is the command-line version of the RSOP snap-in.

The Resultant Set of Policies MMC Snap-in

The RSOP snap-in can be used to show the effective policy settings for a user who logs on to a server or workstation after all the respective policies have been applied. This tool is good for identifying which policies are being applied and what the effective setting is.

To test the policies for a user, use the RSOP snap-in as follows:

1.
Log on to the server or workstation where the user has already logged on.

2.
Choose Start, Run. Then type MMC.exe and click OK.

3.
Choose File, Add/Remove Snap-in.

4.
Click Add in the Add/Remove Snap-in window.

5.
Select Resultant Set of Policy from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.

6.
In the console window, right-click Resultant Set of Policy and select Generate RSOP Data.

7.
Click Next on the Welcome screen.

8.
Choose Logging Mode on the Mode Selection page and click Next.

9.
On the Computer Selection page, select This Computer and click Next.

10.
On the User Selection page, select the Display Policy Settings For radio button and then select the Select a Specific User option, as shown in Figure 19.11.

Figure 19.11. Selecting the specific user for whom you want to gather Group Policy data.

[View full size image]

11.
On the Summary of Selections page, verify that all the correct selections were chosen and click Next to gather the data.

12.
When the snap-in has finished collecting data, click Finish to return to the console and review it.

Within the console, you can review each particular setting to see whether a setting was applied or the desired setting was overwritten by a higher-level policy. To figure out which actual policies have been applied, right-click either the Computer Configuration or User Configuration container and then select Properties to see the list of policies applied for the specified user.


Managing Printers with Print Management Component

The Print Management Component (PMC) was added to Windows 2003 R2 as an add-in component to help organizations better manage and administer printers on an enterprise basis. Prior to the Print Management Component, a network administrator would have to point to each network printer or printer server individually to manage and administer the device. For a large enterprise with hundreds of printers and dozens of printer servers, selecting print servers each time a printer needed to be managed was a very tedious task. Furthermore, if the administrator didn't remember which printer was attached to which print server, finding the printer and print server that needed management could take a while.

The Print Management Component provides a single interface where an administrator can open the Print Management utility and view all printers and print servers in the enterprise. Furthermore, PMC can be configured to group printers together so that certain administrators can manage and administer only certain printers. As an example, if an organization has an administrator for a particular building, the PMC interface can be filtered to list only the printers within the building. This allows the administrator to see only certain printers for which he is responsible, as well as consolidate multiple print server groups of printers into a single interface for management and administration.

The Print Management Component needs to be installed only on the system from which the administrator is managing; it does not need to be installed on all print servers or systems in the enterprise. Functionally, PMC could be installed on just one system.

Installing the Print Management Component

To install the Print Management Component, the Windows 2003 R2 components need to be installed on the system (see the section, "Preparing a System and Installing the Windows 2003 R2 Components," in Chapter 3 for installation instructions). Perform the following steps to enable the Print Management Component option on the system:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Select Start, Settings, Control Panel, Add/Remove Programs.
3. | Click Add/Remove Windows Components, and double-click the Management and Monitoring Tools folder. Select the Print Management Component option and click Next.
4. | Click Next to install the component, and then click Finished when done. The installation of the Print Management Component typically does not require you to restart the server.

Configuring the Print Management Component

After the Print Management Component has been installed on a system, the utility needs to be configured to identify the printers and print servers in the enterprise. Printers can be manually added to the Print Management tool for administration and management, or the network can be scanned to attempt to automatically identify printers in the enterprise.

To configure print management resources, launch the Print Management utility by doing the following:

1.
Select Start, Settings, Control Panel.

2.
Open the Administrative Tools folder and double-click Print Management to launch the Print Management Component.

Upon opening the Print Management Component, a screen will appear similar to the one shown in Figure 19.12.

Figure 19.12. Print Management utility in Windows 2003 R2.

[View full size image]

Adding New Printers as Network Shared Resources

There are two ways to add new printers to a Windows 2003 R2 network. One way is the standard Windows printer installation method of using the Add Printer option. The other option is using the new Print Management utility and adding a printer within the utility. Both methods return the same result, so the main reason to use the Print Management utility method is to simplify all print management tasks of adding, modifying, and managing printers from a single utility.

Using the Add Printer Option in Windows to Add a Local Printer

To add a new printer that is locally attached to a Print Server using the standard Windows Add Printer option method, do the following:

1. | Select Start, Settings, Printers and Faxes.
2. | Click Add Printers to launch the Add Printer Wizard, and click Next to bypass the initial installation screen.
3. | Because the printer is locally attached to the Print Server, select Local Printer Attached to This Computer, and then click Next.
4. | Choose the port (LPT1, LPT2, COM1, COM2, and so on) to which the printer is attached, and then click Next.
5. | Choose the manufacturer and the printer type of the printer being added (such as HP for manufacturer and Laserjet 2200 for printer type), and then click Next.
6. | When prompted, give the printer a name (such as "HP Laserjet 2200 in the Marketing Dept"), and then click Next.
7. | When prompted whether you want to share the printer, select the Share Name option and type in a name that will describe the printer (such as HP2200MKTG), and then click Next.
8. | For location, this is optional, but in an enterprise, it is helpful to describe where this printer is located so that when you want to find a printer, you have a better description of the printer and where it is located. For location, enter something such as Building 11, 2nd Floor, and then click Next.
9. | If you want to do a test page, select Yes; otherwise, choose No, and then click Next.
10. | Click Finish to complete the addition of the printer.
Using the Add Printer Option in Windows to Add a Network-Attached Printer

To add a new printer that is attached directly to the network backbone using the standard Windows Add Printer option method, do the following:

1. | Select Start, Settings, Printers and Faxes.
2. | Click Add Printers to launch the Add Printer Wizard, and click Next to bypass the initial installation screen.
3. | Because the printer is network attached, select A Network Printer, or a Printer Attached to Another Computer, and then click Next.
4. | Enter the printer name or URL of the printer that will be shared (such as \\pserver1\hpljet). Note If the printer has a network adapter built directly into the printer, such as an HP laser printer with a JetDirect Ethernet port on the back of the printer, see the installation manual that comes with the printer. As an example, for HP printers with built-in Ethernet, you would need to install the HP JetDirect software that comes with the printer to assign an IP address to the printer using the HP utility, and then the utility will walk you through the process of publishing the printer on the Windows network. When using the printer vendorprovided utility, you can skip this section.
5. | Choose the manufacturer and the printer type of the printer being added (such as HP for manufacturer and Laserjet 2200 for printer type), and then click Next.
6. | When prompted, give the printer a name (such as "HP Laserjet 2200 in the Marketing Dept"), and then click Next.
7. | When prompted whether you want to share the printer, select the Share Name option and type in a name that will describe the printer (such as HP2200MKTG), and then click Next.
8. | Entering a location is optional, but in an enterprise, it is helpful to describe where this printer is located so that when you want to find a printer, you have a better description of the printer and where to find it. For location, enter something such as Building 11, 2nd Floor, and then click Next.
9. | If you want to do a test page, select Yes; otherwise, choose No, and then click Next.
10. | Click Finish to complete the addition of the printer.
Using the Add Printer Option in the Print Management Component

Another option of adding a printer to the network is to use the Print Management Component utility to add the printer. This process is identical to adding the printer using the Windows Add Printer option addressed in the previous section. However, instead of using two separate interfaces for adding and managing printers, using the Print Management Component option can centralize the tasks into a single interface.

To start the Add Printer Wizard within the Print Management Component, do the following:

1. | Expand the Print Servers section of the Print Management interface.
2. | Right-click one of the print servers listed in the Print Servers section of the interface and choose Add Printer.
3. | If the printer is attached directly to the print server, follow the instructions in the "Using the Add Printer Option in Windows to Add a Local Printer" section of this chapter.
4. | If the printer is attached directly to the network, follow the instructions in the "Using the Add Printer Option in Windows to Add a Network-Attached Printer" section of this chapter.

Adding Print Servers to the Print Management Component

After printers and print servers have been added to the network, as noted in the previous sections, an administrator can begin to add print servers to the Print Management Component to centrally view, manage, and maintain the printers on the network.

Adding a print server to the Print Management Component will allow the administrator to manage the print server and all the printers the print server hosts. To add a print server to the Print Management Component, do the following:

1. | Right-click the Print Servers item in the Print Management utility and choose Add/Remove Servers.
2. | Type in the name of the print server you want to add, or click Browse and search the Microsoft Windows Network to view the various servers in the environment.
3. | Click OK to add the print server.

Using the Print Management Component

With printers added to the network and print servers added to the Print Management Component, an administrator can begin to centrally view, manage, and administer the printers and print servers. Some of the tasks that an administrator can perform from the Print Management Component are tasks that an administrator would normally do right on the print server, such as change printer ports, add or modify forms, or view the status of printers whether the printers are online or not. Other tasks are new to the Print Management Component, such as creating custom printer filters that allow multiple administrators to view and manage selected printers based on their site, rights, and roles.

Performing General Printer Administration Tasks

From within the Print Management Component, the administrator can perform general printer administration task. Some of these tasks include

  • Updating printer drivers By right-clicking the Drivers item on the Print Server section of the Print Management interface and choosing Manage Drivers, an administrator can update or change a printer's printer driver. This is rarely done in a network environment, but there are times when a new printer add-on, such as an envelope feeder or expansion paper feeder or sorter, is added, and a new printer driver is needed to support the new add-on.

  • Forms By right-clicking the Forms item on the Print Server section and choosing Manage Forms, an administrator can create and delete new forms to support different-sized paper or to specify a custom letterhead paper form. Additionally, within this interface an administrator can change the printer port to which a printer is attached on a print server, define log settings, and enable the function to have users notified when a print job has successfully completed printing.

Note

One might wonder when someone would ever create a new printer form or worry about being notified when a print job has been completed, especially when most print jobs are simple 1-page emails or a handful of pages of a Word document. However, a creative use of this feature is used by accounting departments, publishers, or other individuals that print large print jobs. One would want to know when a 400-page document has finished printing, or when 100 sets of a 15-page document are finished printing, collating, and stapling. By creating a custom form, which may just be a simple 8 1/2 x 11-inch form with advanced notifications enabled to notify the user that job has been completed, a user who chooses that form instead of the normal 8 1/2 x 11 form will be notified when the print job has been completed.

Creating Custom Printer Filters

A unique function of the Print Management Component is the Custom Printer Filters function that enables an administrator to group printers typically for the purpose of distributing the administration of printers in the environment. For large organizations that might have multiple buildings, sites, and administration boundaries of devices such as printers, the administrators can perform a filter view to see only the printers that fit within their administrative responsibilities.

First of all, to view all printers in the environment, an administrator can click the All Printers section of the Custom Printer Filters section of the Print Management interface. All the printers for the network will be listed here.

Note

If printers on the network are not listed in the All Printers view, please refer to the section, "Adding Print Servers to the Print Management Component."

To create a custom printers view, do the following:

1. | Right-click the Custom Printers View in the Print Management utility and choose Add New Printer Filter.
2. | Type in a descriptive name for this filter view, such as All Printers in the San Francisco Site or All Printers in Building 11.
3. | In the Field drop-down box, choose a field that will contain information that can be filtered. In many cases, the print servers can be filtered because a print server frequently serves printers in a specific geography. Alternatively, organizations that entered location information for printers, such as Building 11, would be able to filter for that designation in a custom printer filter filtered by name. An example might be Field=Location, Condition=Contains, or Value=Building 11. Click Next to continue.
4. | In the Set Notification options page, an administrator can note an email address where the administrator can be notified on the status of events related to the printers in the filter. This might include being emailed every time a printer is offline or every time a printer is out of paper. Enter the appropriate email information (email address, SMTP mail server to be used, and message desired), or leave this section unchecked, and then click Finish.

By clicking on the newly created filter, the filter rule is applied and the printers noted in the filter will be displayed as shown in Figure 19.13. In this figure, you will notice a designation that there are six printers in the environment; however, the filter is searching only for printers in Building 11, and thus only four printers are displayed for this administrator to view and manage.

Figure 19.13. Sample custom printer filter.

[View full size image]

Virtually an unlimited number of printer filters can be created to show different groupings of printers to be managed or administered. Organizations have created custom printer filters by printer manufacturer, such as HP, Xerox, and Sharp, or by printer type, such as laser, color laser, and plotter, to be able to view assets by make, model, or configuration.


Summary

Managing Active Directory sites, groups, and users can be daunting if some of these tasks cannot be automated or simplified. This chapter outlined ways to create these objects and included the information necessary to manage these objects from a standalone and enterprise level. For more detailed information on these topics, refer to Chapters 5 and 6 for Active Directory design, Chapters 21 and 29 for Group Policy specifics, and Chapter 23 for ideas on how to script simple administrative tasks to reduce manual tasks.


Best Practices

  • Clearly understand your roles and responsibilities in the enterprise network and understand how the different components that make up the network communicate and rely on one another.

  • Choose the appropriate administrative model (central, distributed, or mixed) for the organization based on required services and skillsets in each location.

  • Track licensing usage using a centralized server.

  • Use site policies to define custom network security settings for sites with higher requirements or to delegate administrative rights when administration is performed on a mostly geographic basis.

  • Ensure that sites contain local network services such as domain controllers, global catalog servers, DNS servers, DHCP servers, and, if necessary, WINS servers.

  • Use security groups to create distribution lists.

  • Create a universal group to span domains, but have only a global group from each domain as a member.

  • Keep roaming profiles at small, manageable sizes.

  • Use mandatory profiles to increase security and gain control over the desktop.

  • Use profile templates to minimize the amount of required administration.

  • Use local and group policies to manage users and desktops.

  • Modify Group Policy security entries to limit Group Policy application to specific users or computers.

  • Use RSOP or the command-line utility GPResult.exe to view and troubleshoot the way group policies are applied.

  • Use the Print Management Component added to Windows 2003 R2 to centrally view, manage, and administer printers in the network environment.


Chapter 20. Windows Server 2003 System Registry

In This Chapter

  • Windows Server 2003 Registry Architecture

  • The Windows Server 2003 Registry Editor

  • Protecting the Registry

  • Maintaining the Registry

  • Backing Up the Registry

The concept of a centralized repository of hardware- and software-related information for a system isn't new, but it was perfected starting with Windows 95. This central repository was called the Registry. The Registry was designed to overcome the limitations of .ini and .dat files used in previous Microsoft operating systems.

Since its initial implementation, the concept behind the Registry and its purpose haven't undergone a tremendous amount of change. It remains a database containing hardware, operating system, policy, file association, and application configuration information. It also houses information on users who log on to the system. As you can tell, the Registry is involved in almost every aspect of the system. Because of its involvement, you need to have a solid understanding of the Registry, how to manage and maintain it, and how to secure it from unauthorized access.

Regrettably, the Registry's capabilities and uses are rarely fully understood by system administrators, much less end users. This is partly because of the Registry's complexity and also because of the fact that many users are somewhat intimidated by the warning messages about modifying the Registry. Although it is true that modifications can have disastrous effects on the entire system, Registry changes occur more often than you realize. Most of these changes take place through the GUI, but some system configurations can happen more efficiently either through a manual Registry modification (instead of going through a series of dialog boxes) or only through a manual change.

The Windows Server 2003 Registry is not a piece of the operating system to take lightly. Because Windows Server 2003 relies greatly on the Registry to function, it is critical that you understand the Registry's approach to system configuration. This chapter serves to give you the necessary information to manipulate the Registry so that you maintain system reliability and performance. Overall, this chapter focuses on the following four key topics related to the Windows Server 2003 Registry:

  • Understanding the Registry's structural design

  • Properly using the tools available to manage and maintain the Registry

  • Adequately protecting the Registry

  • Backing up and restoring the Registry


Windows Server 2003 Registry Architecture

The Windows Server 2003 Registry is a well-organized database containing an assortment of hardware-, software-, and user-related information. Its basic structure is hierarchical with multiple configuration layers. These layers or levels are grouped from the top down by hives, keys, subkeys, value entries, and finally the actual value for a given configuration parameter. A value entry is a parameter within the key or subkey, and a value is the specific value for the parameter.

Hives, Keys, and Subkeys

At the topmost level of the Registry's organization is a root key commonly referred to as a hive. There are five hives within the Registry, as shown in Figure 20.1, and they are all permanent (that is, they are hard-coded within Windows Server 2003). Because these hives are hard-coded, you can't delete, modify, or add another hive.

Figure 20.1. Displaying the five Registry hives with the Registry Editor.

[View full size image]

Table 20.1 lists and describes each of these hives.

Table 20.1. The Five Registry Hives and Their Content

Registry Root Key (Hive)

Content Description

HKEY_CURRENT_CONFIG

Current hardware configuration information.

HKEY_CLASSES_ROOT

File associations and OLE information.

HKEY_CURRENT_USER

Information about the user currently logged on, such as desktop settings and network connections.

HKEY_USERS

Local user account information. Information on each user is stored in a separate subkey.

HKEY_LOCAL_MACHINE

System configuration information and parameters, such as hardware, software, and security settings.

Coincidentally, some of the hives are also subkeys of other hives and are linked to one another. These hives and their corresponding linked paths are listed in Table 20.2.

Table 20.2. Registry Hive Links

Hive (Root Key)

Linked Path

HKEY_CLASSES_ROOT

HKEY_LOCAL_MACHINE\SOFTWARE\Classes

HKEY_CURRENT_CONFIG

-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current

HKEY_CURRENT_USER

HKEY_USERS (current user logged on)

The next organizational level is a key. Each key contains value entries or values and can also have subkeys branching off it. Those subkeys can then be considered keys for the configuration information branching off it.

Registry Location and Storage

The Windows Server 2003 Registry is stored in two separate places: in memory and on disk. At startup, the entire Registry is loaded into paged, pooled memory so that Windows Server 2003 can quickly retrieve information.

It's also stored in various files located within the %SYSTEMROOT%\System32\Config directory. You'll also notice the .sav and .log files in this directory. They serve as backup files for the Registry.

HKEY_LOCAL_MACHINE

The HKEY_LOCAL_MACHINE hive contains a variety of information pertaining to hardware devices (for example, memory, bus types, device drivers, and more) and the software installed on the system. As you can see in Figure 20.2, the hive contains the following five subkeys:

Figure 20.2. HKEY_LOCAL_MACHINE subkeys.

[View full size image]

  • HARDWARE

  • SAM

  • SECURITY

  • SOFTWARE

  • SYSTEM

These five subkeys are explained in the following sections.

The HARDWARE Subkey

As the name implies, the HARDWARE subkey contains all the hardware information for the system. When the system starts up, information is built about the hardware, and then at shutdown this information is wiped away. Therefore, the HARDWARE subkey is volatile.

NTDETECT.COM is in charge of gathering all information on the hardware. After it obtains the information, it passes that information to the HARDWARE subkey. The following are some examples of the hardware components that it detects:

  • Adapter type

  • Bus type

  • Communication ports

  • Floppy disks

  • Keyboard

  • Mouse

  • Video

There are four subkeys within the HARDWARE subkey. These subkeys are also populated with information gathered from NTDETECT.COM. The four standard subkeys are the following:

  • HARDWARE\ACPI This subkey is for the ACPI hardware and software interface specification that supports Plug and Play as well as advanced power management (APM).

  • HARDWARE\DESCRIPTION This subkey contains hardware descriptions.

  • HARDWARE\DEVICEMAP This subkey includes devices to device driver mappings.

  • HARDWARE\RESOURCEMAP This subkey contains resource mappings that the devices use (such as physical memory ranges).

Note

Plug and Play APIs are used to read and write power management and Plug and Play device information from and to the Registry dynamically.

The SAM Subkey

The SAM subkey, shown in Figure 20.3, is similar to the HKEY_LOCAL_MACHINE\ SECURITY subkey in that it contains valuable information. By default, this subkey is locked down to the point that it's inaccessible to users via the Registry Editor. It stores local users and groups, along with access permissions for files and folders.

Figure 20.3. The HKEY_LOCAL_MACHINE\SAM subkey.

[View full size image]

The SECURITY Subkey

Because of the security-sensitive information contained in the SECURITY subkey, it too is locked down tightly to protect the information. This subkey is, by default, inaccessible through the Registry Editor.

The information within this key pertains to users, groups, access permissions, and also includes application and device driverrelated information. The actual content of this subkey is determined whether or not you're still in Mixed mode with Windows NT 4 as a domain controller.

The SOFTWARE Subkey

Application-specific information including, but not limited to, path statements, licensing, and executable paths is stored in the SOFTWARE subkey. Because this subkey resides under the HKEY_LOCAL_MACHINE key, the configuration information is applied globally (that is, systemwide). This is an important point because these configurations differ from those located in HKEY_CURRENT _USER\Software for individual users.

Within this subkey, you'll also find various other subkeys relating to the applications that are installed on the system. For example, under HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\, you can find the configurations and version numbers of all the Microsoft-installed software.

The SYSTEM Subkey

Another sensitive subkey that is very important to Windows Server 2003 is the SYSTEM subkey. The majority of the information stored in this subkey is the following:

  • Control set configurations The control set configuration pertains to the data that is needed to control the system boot process. This information is associated with current and prior control sets. The current control set defines the system profile, while its subkeys provide more detail, such as the computer name, the services running on the system, and instructions for Windows Server 2003 in case of a system crash.

  • Windows Server 2003 setup information This information contains various Windows Server 2003 setup parameters, such as OSLoaderPath and SystemPartition.

  • Disk subsystem configuration The disk subsystem configuration information pertains to the devices, volumes, RAID settings, and more. The Disk Management snap-in uses this information to display the disk subsystem information.

HKEY_CLASSES_ROOT

Although HKEY_CLASSES_ROOT is considered a hive, it's actually an alias for the key HKEY_LOCAL_MACHINE\SOFTWARE\Classes. This key stores all file associations, information regarding shortcuts, OLE, and much more. The file association basically points to the appropriate application that will execute when you use a file with that specific extension. Also, particular icons are associated with a particular file type. So, for example, when you view files in Windows Explorer, you can see a document (.doc) with a Microsoft Word icon. When you open that file, Microsoft Word is launched and opens the file. Some of the file associations are shown in Figure 20.4.

Figure 20.4. File associations located in HKEY_CLASSES_ROOT.

[View full size image]

The HKEY_CURRENT_USER\Software\Classes alias was first introduced and implemented in Windows 2000 to enhance support for user-based settings. This feature is called per-user class registration. It provides more flexibility and customization by allowing applications to define associations per user as needed. In other words, a system with multiple users can have different application settings for each individual.

HKEY_CURRENT_CONFIG

The HKEY_CURRENT_CONFIG is yet another hive that aliases another subkey. This time it references HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\ Current. If you check this reference, you'll notice that there really isn't any particularly useful data in this subkey because it's really just a pointer to a numbered subkey that has the current hardware profile.

As you would expect, the data contained within this hive is hardware profilerelated information. Windows Server 2003 systems use hardware profiles by default, and you can add more depending on the hardware configuration changes you'll have. For the most part, mobile users will have more than one profile.

HKEY_CURRENT_USER

The HKEY_CURRENT_USER is a unique and dynamic hive. It's unique in that it contains information on the currently logged-on user and more specifically maps to HKEY_USERS\<SecurityID>, where the SID represents the user. It's dynamic because each time a user logs on, the key is refreshed and built from scratch.

The information contained within this key varies depending on the particular user logging in. Generally speaking, it includes information such as user preferences (keyboard mappings, desktop settings, network drive connections, application-specific preferences, and much more). In the case where the user logs on to the system for the first time, a default user profile is used.

There are several subkeys underneath the HKEY_CURRENT_USER hive, including, but not limited to, the following subkeys:

  • AppEvents

  • Console

  • Control Panel

  • Environment

  • Identities

  • Keyboard Layout

  • Printers

  • Session Information

  • Software

  • Unicode Program Groups

  • Volatile Environment

HKEY_USERS

The HKEY_USERS subkey represents the currently loaded user profiles. It contains a subkey for each user, but only two subkeys for the user currently logged on and the default user profile appear. The three loaded profiles are the following:

  • .DEFAULT During startup, this is the default profile used before a user is logged on to the system. In other words, if no one is logged on to the system, this is the only profile in use.

  • <SecurityID> Also known as the SID, this profile identifies the user currently logged on.

  • <SecurityID_Classes> This profile represents all the class information for the user currently logged on.

Each user profile is loaded from the disk subsystem, not from the Registry itself. The default location of the profiles is located in %SystemDrive%\Documents and Settings\<user_name> or %SystemDrive%\Documents and Settings\Default User\.


The Windows Server 2003 Registry Editor

Windows Server 2003 predecessors were configured with two versions of the Registry Editor: REGEDIT.EXE and REGEDT32.EXE. Each one had its own strengths, but it was inconvenient at best to have to use both versions depending on what you set out to do. Fortunately, Microsoft has done away with using two versions. The best of both versions is now incorporated into a single Registry Editor. Both executables (REGEDIT.EXE and REGEDT32.EXE) still exist, but they launch the same utility, like the one shown in Figure 20.5. With Windows Server 2003's single Registry Editor, you can directly modify the local or remote system's Registry, set key permissions, and more.

Figure 20.5. Visible HKEY_USERS subkeys.

[View full size image]

Modifying Registry Entries

The Registry Editor enables you, the administrator, to modify the Registry. For example, you can add keys or subkeys, change parameter values, and much more. Because you have so much control over the Registry, it's important that you back up the Registry before making any modifications. This will help prevent accidental Registry corruption or, in the worst case, a system crash. For more information on how to back up the Registry, refer to the section "Backing Up the Registry" later in this chapter.

Adding a Key

You can add a key in almost every area within the Registry. Some exceptions include the following:

  • At the Registry's root level

  • At the root level of certain hives (such as HKEY_LOCAL_MACHINE and HKEY_USERS)

  • Within the HKEY_LOCAL_MACHINE\SECURITY (by default)

To begin adding a key, follow these steps:

1. | Open the Registry Editor from the Run line or command prompt by typing regedit or regedt32.
2. | Expand to the key where you want to add another key (subkey).
3. | Right-click the key and select New, Key.
4. | Type in the name of the key. You can now set a value for the Default value entry if needed.
Adding a Value

To add a value to a specific key, right-click the key (in the left pane) and select one of the values listed in Table 20.3. The type of value you select determines the type of information for the value.

Table 20.3. Various Value Types

Value Item

Description

String value

A fixed-length text string usually representing a description.

Binary value

Raw binary data that can be displayed in hexadecimal (hex) format. Can be used with hardware components.

DWORD value

A 32-bit number that can be displayed in binary, hex, or decimal format.

Multi-string value

Contains several multiple string values separated by a null character. For example, it could contain other Registry locations.

Expandable string value

Contains lists or multiple values, such as system environment variables, in a readable format, similar to the multi-string value. Strings can be separated by commas, spaces, or null characters.

Changing a Value

Sometimes you may need to modify a particular value to increase performance, add functionality, and so on. To change a value, follow these steps:

1. | In the left pane of the Registry Editor, select the key that contains the value that you want to manipulate.
2. | Double-click the value entry in the right pane.
3. | Change the value to the new one according to the value's data type.
4. | Click OK.
Removing a Key or Value

Deleting a Registry key or value is by far the easiest but most dangerous option you have. All you have to do is either press the Delete key or select Delete from the Edit menu.

Searching the Registry

Searching the Registry used to be a task handled primarily by regedit, but now that functionality is built into this single Registry Editor. To search for a key, value, or data, perform the following steps:

1. | Within the Registry Editor's left pane, select My Computer.
2. | Select Find from the Edit menu.
3. | In the Find dialog box, type the key name, value name, or data value that you want to search for.
4. | Choose what to look for (such as keys, values, data) and whether to match whole strings only.
5. | Click Find Next to start the search.

Working with Favorites

Just like the Favorites menu within Internet Explorer, the Registry Editor's Favorites menu allows you to save links to particular locations within the Registry. When you save a link to the Favorites menu, the next time you need to revisit the key, you can quickly jump to the location using a bookmark.

Connecting to a Remote Registry

To connect to a remote Registry, perform the following steps:

1.
Open the Registry Editor by entering regedit or regedt32 at the command prompt.

2.
Select Connect Network Registry from the File menu.

3.
In the Select Computer dialog box, like the one shown in Figure 20.6, type the computer name into the window.

Figure 20.6. Selecting a remote Registry.

4.
Click Check Names to verify the computer name that you entered is correct.

5.
Click OK to connect to the remote Registry.

After you connect to the remote Registry, you can modify its HKEY_LOCAL_MACHINE and HKEY_USERS hives just as you would the local machine's Registry.


Protecting the Registry

The information contained within the Registry is vital to the reliability, stability, and performance of the system. Protecting the Registry is therefore critical to the system's operation.

Microsoft has done a much better job setting secure default permissions in Windows Server 2003 than it did with its previous operating systems. Registry permissions are no exception. There is limited access to the Registry even for system administrators. For example, the HKEY_LOCAL_MACHINE\SAM and HKEY_LOCAL_MACHINE\SECURITY keys give administrators only read and write DAC access by default.

If your system requires tighter access controls than the default permissions, you can set them accordingly from within the Registry Editor. Registry permissions are configured on a per-key basis, but subkeys can inherit permissions from parent keys. Setting Registry key permissions is similar to setting permissions to files and folders within the NTFS file system. To set Registry key permissions, perform the following steps:

1. | Within the Registry Editor, right-click the key for which you want to modify permissions and select Permissions.
2. | The most common permission attributes used are displayed on the Permissions for <key> window. Specify Allow or Deny for the Full Control, Read, or Special Permissions settings.
3. | If you want more granular control, click the Advanced button to display the Advanced Security Settings for <key>. Select the permissions that the key requires.

You can set numerous permissions within the advanced security settings for a particular key, including the following:

  • Full Control

  • Query Value

  • Set Value

  • Create Subkey

  • Enumerate Subkey

  • Notify

  • Create Link

  • Delete

  • Write DAC

  • Write Owner

  • Read Control

Preventing Remote Access

In some cases you may want to control remote access into a system's Registry. You can do this by setting permissions in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg key. By default, only administrators, backup operators, and the LOCAL SERVICE have access permissions to connect from another system.

You may want to change the default permissions when you want only specific administrators or backup operators to have access. In this case, you could remove the default Administrators and Backup Operators groups and replace them with specific user accounts.

Auditing the Registry

Auditing the Registry may be beneficial in your network environment for security reasons, troubleshooting, or just general observation. No matter the reason, the auditing capabilities with Windows Server 2003 are very powerful and flexible.

Two essential steps must take place before you can begin auditing the Registry. First, you must enable successes or failures either through a Group Policy Object (GPO) or a local policy (it's disabled by default). For more information on GPOs, refer to Chapter 21, "Windows Server 2003 Group Policies." The next step after enabling auditing is to specify what Registry keys to audit and to what extent from within the Registry Editor.

To enable auditing through a GPO, perform the following steps:

1. | Open Active Directory Users and Computers from the Start, Administrative Tools menu.
2. | In the right pane, right-click the domain and select Properties.
3. | Click the Group Policy tab.
4. | Select the Default Domain Policy object or a specific GPO that you want to use for auditing.
5. | Click Edit and then expand to Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy.
6. | Double-click the Audit object access setting.
7. | Check the Define These Policy Settings box and then check either Success or Failure.
8. | Click Apply and then OK to close the GPO editor.

To enable auditing through the local policy, follow these steps:

1. | Open Local Security Policy (or Default Domain Controllers Security Setting) from the Start, Administrative Tools menu.
2. | Expand Local Policies and select Audit Policy.
3. | Double-click the Audit object access.
4. | If the Define These Policy Settings box isn't already checked, do so and then check either Success or Failure.
5. | Click on Apply and then OK to close the GPO editor.

Now you're ready to specify what to audit within the Registry. To begin auditing the Registry, perform the following steps:

1. | Within the Registry Editor, right-click the key that you want to audit and select Permissions.
2. | Click the Advanced button to display the Advanced Security Settings for <key>. Select the permissions that the key requires.
3. | Select the Auditing tab and click the Add button.
4. | In the Select User or Group dialog box, enter the users or groups that you want to monitor. For example, you can type auth and then click Check Names to populate the Authenticate Users group.
5. | Click OK. This will bring up the Auditing Entry for <key> dialog box.
6. | Select Successful and/or Failed for each access to audit. Note that checking Successful or Failed for Full Control will enable all other accesses.
7. | Check the Apply These Auditing Entries to Objects and/or Containers Within This Container box only if you want to minimize what you are auditing.
8. | Click OK three times to return to the Registry Editor.
9. | Close the Registry Editor.

Analyzing Event Logs

After you've established auditing on the Registry, you can examine the results in the Event Viewer, like the events shown in Figure 20.7. Auditing is a security-related event, so any auditing events are written to the security log.

Figure 20.7. Examining the Registry access in the security log.

Note

The default size of the security log in Windows Server 2003 is 131072KB (128MB). This is an adequate size for auditing. If you're auditing many different components, increasing the maximum log size is recommended.


Maintaining the Registry

Windows Server 2003's self-sufficiency spills over into what's needed to maintain the Registry. Little is needed to maintain the Registry, but the few things you can do will make the overall system more robust.

Managing Registry Size

In previous versions of Windows, the operating system limited the size of the Registry. This limit was based on the paged, pooled memory availability and its size. Beginning with Windows XP, this limitation has been removed.

Registry files are now mapped in the computer cache rather than the paged, pooled memory. Windows Server 2003 keeps an eye on the Registry size, which means that you no longer have to specify Registry sizes in the virtual memory settings. In fact, you don't even have a Registry size option in the virtual memory settings.

Although Windows Server 2003 relinquishes much of the Registry size responsibility, you need to be aware of two important considerations. First, it's important that you keep an adequate amount of free space available on the system partition. Generally, all drives should have at least 25% free space at all times.

The second consideration is routinely defragmenting all drives on the system. This will allow the system to operate efficiently and keep the Registry size in check.

Keeping the Registry Fit

Many configuration and technical details are contained within the Registry's hierarchical structure. The actual contents more than likely change every day. In addition, any time you add, modify, or remove an application, service, or device driver, the majority (if not all) of those changes are mirrored within the Registry.

As you can imagine, the changes that the Registry undergoes can leave it fragmented just like any other database structure would go through. Other times, Registry entries may contain invalid data or may still exist long after a component was removed. Often this is a result of poor programming or insufficient utilities rather than Windows Server 2003.

Although application reliance on the Registry is lessening because of the Windows .NET development framework, many applications and utilities still don't properly interact with the Registry, especially when it comes to uninstalling the application or device driver. It's important to note here that applications are singled out more so than hardware components because the Registry's hardware inventory process is dynamic.

Like any other database, the leaner the Registry is, the more robustly and efficiently it can operate. The Windows Server 2003 Registry must be kept clean, which means that periodically the Registry should go through spring cleaning to remove invalid data and remnants.

Cleaning the Registry

Most applications come bundled with an uninstall utility that attempts to remove itself, its data, and any Registry entries that it created. For those applications that do not, you are faced with removing the application by hand. This is undesirable and painstaking at best. Manually removing these rogue application entries also can introduce the unnecessary risk of damaging the Registry.

Several years ago, Microsoft developed a small utility called RegClean. The essential function behind this utility was to remove the clutter (such as invalid or rogue entries) from the Registry. This tool isn't officially supported on the Windows 2000 or Windows Server 2003 platforms, but independent testing has shown successful results. If you plan on using this utility, it is highly recommended that you extensively test it in a lab environment to ensure its compatibility.

You can use other utilities both within Windows Server 2003 and third-party tools to assist you in removing clutter and keeping the Registry lean and mean.

The Add/Remove Programs Applet

Through the Add/Remove Programs applet, shown in Figure 20.8, available from the Control Panel, Windows Server 2003 provides its own way of removing applications. Most applications can be installed and removed through this applet. Although the applet may appear to be useful in keeping the Registry free of clutter, it usually just kicks off an application's uninstall utility.

Figure 20.8. The Add/Remove Programs applet.

[View full size image]

Windows Installer Cleanup Utility (MSICUU.EXE)

The Windows Installer Cleanup Utility is designed exclusively to remove Registry entries from applications that were installed using the Windows Installer. It doesn't delete application files or remove shortcuts; it deletes only the application's Registry entries. This utility is installed on your system after you install the Windows Server 2003 support Tools. When you double-click the deploy.cab file, it will automatically install several utilities in the Administrative Tools folder on your system.

MSICUU, shown in Figure 20.9, can also be used to return to the system state prior to an abrupt termination or failed application installation using the Windows Installer.

Figure 20.9. The Windows Installer Cleanup utility.

After you install the Support Tools from the Windows Server 2003 CD, follow these steps so that you can use MSICUU:

1. | From the command prompt, type MSICUU and then press Enter.
2. | When the MSICUU program is displayed, you can then select the program or programs for which you want to remove Registry entries. It is recommended that you choose only one program at a time to minimize any complications.
Windows Installer Zapper (MSIZAP.EXE)

The command-line version of MSICUU is the Windows Installer Zapper utility, also commonly known as MSIZAP. MSIZAP has a little more functionality than the MSICUU GUI utility, such as removing folders in addition to Registry entries. It also can change access control list (ACL) permissions and remove rollback information.

MSIZAP has the following syntax:

MSIZAP [*] [A] [P] [T {product code}] [!]

where

* removes all folders and Registry entries, adjusts shared DLL counts, and stops the Windows Installer service.

T removes all information for the product code specified.

P removes the In-Progress subkey from the Registry.

S removes rollback information.

A changes ACLs to Admin Full Control.

! forces a Yes response to any prompt for the user.

Note

You must have administrative rights to be able to run the MSIZAP utility.


Backing Up the Registry

Whenever you're planning backup and recovery strategies, it's extremely important that you include the Registry. It's also important to back up the Registry before you begin any modifications so that if you accidentally delete a value or key, you can quickly recover.

Routinely backing up the Registry is crucial to the system's well-being. If it becomes corrupted either directly or indirectly, it can cripple the entire system. Backups give you a near fail-safe way to minimize downtime and keep the system operating as efficiently as possible.

Using Backup Utility

Windows Server 2003 comes with reliable backup utility called Backup Utility (ntbackup.exe), shown in Figure 20.10. To access it, choose Start, Programs, Accessories, System Tools. Backup Utility is very similar to the one provided with Windows 2000, with one exception: You use the Automated System Recovery (ASR) feature rather than create an Emergency Repair Disk (ERD). The reason for this change is simply because the information needed to repair a system can't squeeze onto a floppy disk.

Figure 20.10. Windows Server 2003's Backup Utility.

[View full size image]

Backing up the Registry with Backup Utility couldn't be any easier. All you need to do is select the System State Data option. This will back up the Registry along with AD, the SYSVOL directory, system files, boot files, COM+ class registration, and cluster-related information. As you back up the system state data, the Registry files are also automatically saved in the %SYSTEMROOT%\Repair\Regback directory.

Using Automated System Recovery

Automated System Recovery replaces the ERD functionality in Windows Server 2003. The principles are similar to the former recovery mechanism (that is, ERD), but the implementation is quite different. To begin using the ASR, start Backup Utility and choose the ASR option on Backup Utility's opening screen, like the one shown in Figure 20.11. Microsoft recommends using ASR as a last resort only. You should always try recovering the system with the Last Known Good or Safe Mode Boot options.

Figure 20.11. The ASR option.

[View full size image]

By choosing the ASR option, you initiate the ASR Wizard, which automatically backs up the system state, services, and disk configuration information. It uses a floppy disk to contain information about the ASR and the ways to restore the information but then uses other media to actually back up the data. This doesn't mean that it backs up data files that you've created; this just means that it backs up the system state data and the other information mentioned earlier.

You should restore a system using ASR only after you've exhausted all other recovery procedures. It's not that the process is difficult, but it can take a considerable amount of time. You start the ASR recovery by booting off the Windows Server 2003 CD and then pressing F2 during the text portion of setup. Then you place the ASR floppy into the floppy drive when prompted. Then you'll need to follow other instructions on the screen for your specific system.

Backing Up Individual Keys

The Windows Server 2003 Registry Editor allows you to save individual keys by exporting the keys to a registration (.reg) file. This file can later be used to import Registry information into the Registry.

Note

It's recommended that you save a Registry key before attempting to modify that key. If a mistake was made, the registration file could quickly and easily repair the key.

To save a key or subkey using the Registry Editor, right-click the key or subkey that you want to save and select Export. Then specify the filename (with a .reg extension) and the location. Finally, click Save to save the Registry key.

Speeding Up Individual Key Backups

The Registry Editor has a little-known command-line option to quickly and easily export data from the Registry. By running regedit /e <c:\outputfilename.reg> within the command prompt, you can export the entire Registry.

Restoring Individual Registry Keys

You can restore a previously saved Registry key in two ways: double-clicking or importing a registration file. The first choice is fairly obvious; all you need to do is locate the .reg file and then double-click it to be able to populate the information into the Registry.

To restore a previously saved key by importing the key, perform the following steps:

1. | Open the Registry Editor by typing regedit at either the command prompt or the Run line.
2. | Select Import from the File menu.
3. | Specify the location and filename of the registration file and click Open.


Summary

As you can see, the Registry contains a plethora of information regarding the Windows Server 2003 system all in a centralized location. This information is critical to the well-being of the system. Therefore, the Registry should be handled with the best of care. This includes properly maintaining the Registry, routinely backing up the Registry, and knowing how to properly manipulate its configuration.


Best Practices

  • Because you have so much control over the Registry, it's important that you back up the Registry before making any modifications. This will help prevent accidental Registry corruption or, in the worst case, a system crash.

  • Use the Registry Editor's Favorites menu to save links to particular locations within the Registry.

  • Control remote access into a system's Registry by setting permissions in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers_\ winreg key.

  • Increase the maximum log size if Registry auditing is enabled.

  • Manually delete application files and shortcuts after using the Windows Install Cleanup utility.

  • Whenever you're planning backup and recovery strategies, be sure to include the Registry.


Chapter 21. Windows Server 2003 Group Policies

In This Chapter

  • Leveraging Group Policies

  • General Best Practices for Group Policy Deployment

  • Understanding GP Inheritance and Application Order

  • Understanding the Effects of Slow Links on Group Policy

  • Using Tools to Make Things Go Faster

  • Linking Group Policies

  • Automating Software Installations

  • Enhancing Manageability with Group Policy Management Console

  • Using Resultant Set of Policies in GPMC

  • Understanding Windows Management Instrumentation

  • Maximizing Security with Group Policy

  • Getting the Most Out of Folder Redirection

  • Other Useful Tools for Managing Group Policies

  • Using Administrative Templates

  • Modifying Administrative Templates

  • Working with Group Policy Objects

  • Working Within the Group Policy Snap-in Namespace

Policies, historically known as "system policies," have existed in Windows products for many server versions. However, with Windows Server 2000 and now Windows Server 2003, group policies have become an integral part of the operating system. Group policies are used to deliver a standard set of security, controls, rules, and options to a user. In addition, they can be used to configure everything from login scripts and folder redirection to disabling Active Desktop and preventing users from installing software on their workstations.


Leveraging Group Policies

Group policies only apply to Windows 2000 Professional, Windows XP, Windows 2000 Server, and Windows Server 2003 server machines. Any machines running earlier versions of Windows, Unix, or other operating systems will not receive a group policy from Windows Server 2003. Machines receiving group policy settings also must be members of the domain. There are two areas to which group policies can be applied. One is applied to computers and the other is applied to users.

Using Computer Policies

Computer policies are applied upon boot of the machine, are in place before logon, and are independent of the user login credentials. They apply to the computer only, regardless of who will be logging in. Types of group policies that are best applied in the computer policies include things like:

  • Startup scripts

  • Security settings

  • Permission configuration on local files, Registry hives, or services on a workstation

Software installation can be pushed if they are in an MSI format using either the user or computer policies. However, it is suggested that it be pushed via computer policies.

Using User Policies

User policies are applied when the user logs in and occur after boot and during login. They apply to the user regardless of what computer or server the user is logging into. They follow the user wherever the user goes in the domain.

Types of group policies that are best applied in the computer policies are as follows (also not a complete list):

  • Login scripts

  • Restrictions on user rights

  • Folder redirection

Understanding Group Policy Refresh Intervals

Group policies are refreshed at regularly scheduled intervals after a computer has been booted and a user has logged in. By default, group policies are refreshed every 90 minutes on non-domain controllers (with a stagger interval of 30 minutes) and every five minutes on domain controllers.

Refresh intervals are configurable via Group Policy by going to the following areas in Group Policy and changing the refresh interval times:

  • To change the interval for computer policies and DCs, choose Computer Configuration, Administrative Templates, System, Group Policy.

  • To change the interval for user policies, choose User Configuration, Administrative Templates, System, Group Policy.

Most changes made to existing Group Policy Objects (or GPOs) or new GPOs will be enforced when the refresh cycle runs. However, the following settings will be enforced only at login or upon boot, depending on the GPO configuration settings:

  • Software installation configured in the computer policies

  • Software installation configured in the user policies

  • Folder Redirection setting configured in the user policies.

Note

Computer Configuration security settings are refreshed every 16 hours whether or not the settings have been changed.


General Best Practices for Group Policy Deployment

Group Policy usage and configuration can vary greatly with each individual implementation. How GP is implemented can depend on the organization's users, sites, corporate culture, and a myriad of other factors. However, there are basic best practices that apply no matter what the Group Policy implementation. The following sections describe the basic best practices and lessons that have been learned through multiple GP implementations in many different organizations.

The Fewer Policies, the Better: The "Less Is More" Approach

The primary thing to remember with Group Policy is that less is more. Group Policy is very useful and administrators new to it frequently apply a great many group policies, using Group Policy as the elixir for all administrative issues. However, it's important to remember that with each Group Policy Object that is implemented and with each new layer of Group Policy, a fraction of a second is added onto computer boot time and user login time. Additionally, the GPOs take up space in SYSVOL on domain controllers, causing replication traffic as well as adding complexity that can make troubleshooting more difficult.

Knowing Resultant Set of Policies (RSoP)

The new Group Policy Management Console (GPMC) provides you with a handy tool for planning and testing Group Policy implementations prior to implementing them. Because Group Policy can cause tremendous impact on users, any Group Policy implementation should be tested using the RSoP tool in planning mode. See the sections titled "Using Resultant Set of Policies in GPMC" and "Group Policy Modeling Using Resultant Set of Policy" for more information.

Group Policy Order of Inheritance

Group Policy can be configured on many different levels and, by default, is implemented in a particular order. However, by using the Block Policy Inheritance, Enforcement, and Link Enabled conditions, the default order of application can be changed. It's a good idea to use these conditions sparingly because they can add a great deal of complexity to troubleshooting problems with the Group Policy application. See the sections titled "Understanding GP Inheritance and Application Order" and "Modifying Group Policy Inheritance" later in this chapter for more information.

Knowing the Impact of Slow Link Detection

Slow link detection can change the group policy that a user receives, which can be a difficult thing to troubleshoot as an administrator. Understanding the importance of slow links can make troubleshooting a great deal easier for you if you have WAN links that may go up and down or work in an environment with bandwidth issues. See the section in this chapter titled "Understanding the Effects of Slow Links on Group Policy" for more information.

Delegating GP Management Rights

It is important to delegate the proper rights for administrators to manipulate Group Policy. For example, a very small group of users should be able to edit policies on the domain level, but it might be necessary to allow diverse groups of administrators to configure group policies lower down the AD tree in areas in which they administer. An administrator can delegate the following rights to other administrators:

  • Create GPO

  • Create WMI filters

  • Permissions on WMI filters

  • Permissions to read and edit an individual GPO

  • Permissions on individual locations to which the GPO is linked (called the scope of management or SOM)

Using the Group Policy Delegation Wizard makes it easy to give the right groups of administrators the rights they need to do their job, and continue to administer Windows Server 2003 in the most secure ways possible.

Avoiding Cross-Domain Policy Assignments

Avoiding cross-domain policy assignments is a recommended best practice. The more local the policies are, the more quickly the computers boot up and the users can log on, as the users or machines don't have to go across domain lines to receive group policies from other domains. This is especially pertinent for remote users.

Using Group Policy Naming Conventions

The impact of using Group Policy naming conventions cannot be overstated. Naming conventions allow for easier troubleshooting and identification of policies and simplify managing group policies, especially in a large environment.

Using a Proper Naming Convention

  • Use common naming conventions for similar policies ("Site Name Software Policy," or "OU Name Default Policy") rather than a different naming convention for similar policies. For example, begin Group Policy names with the name of the OU or site to which it applies.

  • Use descriptive naming for Group Policy Objects. Don't use the default "New Group Policy" for any policy. If it's a software push policy, label it as such.

  • Use unique names. It is not recommended to name two group policies the same nameespecially in different domains or forests.

Understanding the Default Domain Policy

The default domain policy is the domain-level policy that is installed (but not configured) when Windows 2003 is installed. It should not be renamed, removed, deleted, or moved up or down in the list of group policies that exist on the top level of the domain. Certain security settings will only function properly when implemented in the Default Domain Policy (see the following Warning). It's also a good idea to lock down the capability to edit the Default Domain Policy to a small number of administrators because security settings and other domainwide policies are set at that level.

Warning

Account Policy settings applied at the OU level affect the local SAM database, not Active Directory accounts. The Account Policy settings must be applied on the Default Domain Policy to affect Active Directory accounts.

By understanding and using these generic best practices, you can provide users with a more secure, faster running, and uniform application of group policies.


Understanding GP Inheritance and Application Order

Understanding the order in which Group Policy is applied is essential to administering it successfully. Without a clear understanding, Group Policy implementation and troubleshooting can be very difficult, even with the tools provided by Microsoft to help out with those very things.

Best Practices for Group Policy Inheritance

To maximize the inheritance feature of Group Policy, keep the following in mind:

  • Isolate the servers in their own OU. Create descriptive Server OUs and place all the nondomain-controller servers in those OUs under a common Server OU. If software pushes are applied through Group Policy on the domain level or on a level above the server's OU and do not have the Enforcement option checked, the server's OU can be configured with Block Policy Inheritance checked. As a result, the servers won't receive software pushes applied at levels above their OU.

  • Use Block Policy Inheritance and Enforcement sparingly to make troubleshooting Group Policy less complex.

Understanding the Order in Which Group Policy Objects Are Applied

As stated previously, Group Policy Objects are applied in a specific order. Computers and users whose accounts are lower in the Directory tree can inherit policies applied at different levels within the Active Directory tree. Group Policy Objects are applied in the following order throughout the AD tree:

  • Local Security Policy

  • Site GPOs

  • Domain GPOs

  • OU GPOs

  • Nested OU GPOs

Nested OU GPOs and on down are applied until the OU at which the computer or user is a member is reached.

If a setting in a Group Policy Object is set to Not Configured in a policy higher up, the existing setting remains. However, if there are conflicts in configuration, the last Group Policy Object to be applied prevails. For example, if a conflict exists in a Site GPO and in an OU GPO, the settings configured in the OU GPO will "win."

If multiple GPOs are applied to a specific AD Object such as a site or OU, they are applied in reverse of the order they are listed. The last GPO is applied first, and therefore if conflicts exist, settings in higher GPOs override those in lower ones. For example, if a Contacts OU has the following three group policies applied to it and they appear in this order (as shown in Figure 21.1), the policies will be applied from the bottom up:

Figure 21.1. Group Policy Object order.

[View full size image]

  • Contacts Default Group Policy

  • Contacts Software Policy

  • Contacts Temporary Policy

The Contacts Temporary Policy will be applied first, the Contacts Software Policy will be applied next, and finally the Contacts Default Group Policy will be applied. Any settings in the Contacts Default Group Policy will override the settings configured in the two policies below, and the settings in the Contacts Software Policy will override any settings in the Contacts Temporary Policy.

Modifying Group Policy Inheritance

The Block Inheritance and Enforcement and Link Enabled features allow control over the default inheritance rules. GPOs can be configured to use the Enforcement feature. This setting does not allow the parent organizational unit to be overridden by the settings of the child OU if conflicts exist. Additionally, it nullified the effects of Block Policy Inheritance if that functionality is applied on sub-GPOs.

GPOs can also be set to Block Policy Inheritance. This feature prevents the AD object that has the GPO applied to it from inheriting GPOs from its parent organizational unit, site, or domain (unless the parent GPO had Enforcement enabled as described previously).

Finally, the option exists that allows for the disabling of a Group Policy Object, also known as the GPO's Link Enabled status. By right-clicking on the group policy in the Group Policy Management Console and unchecking Link Enabled, you can disable the policy and render it unused until the time it is re-enabled. In Figure 21.2 the Contacts Temporary Policy Link Enabled state is disabled.

Figure 21.2. Disabling Link Enabled status.

[View full size image]

Configuring Group Policy Loopback

Loopback allows Group Policy to be applied to the user logging in based on the location of the computer object, not the location of the user object in AD. Loopback applies a group policy based on the computer the user is using, not the user who is logging into the computer. An example of a good use of the loopback option concerns Terminal Services. If you need to apply specific permissions to everyone who logs into a particular Terminal Server, regardless of their user group policies, loopback in replace mode will accomplish this objective by ignoring all user GPOs. Loopback also provides a merge mode that merges the GPOs that apply to the user and computer, but gives precedence to the computer GPOs, overriding any conflicting user GPOs.


Understanding the Effects of Slow Links on Group Policy

A slow link is the speed it takes for a packet to get from one site to another. If the time the packet takes to reach the other site exceeds Microsoft's preconfigured slow link threshold, the link is determined to be slow.

What Is the Effect of a Slow Link on a Site?

Microsoft Windows Server 2003 has a default determination of what constitutes a slow link between sites and automatically changes what group policies are provided to a user on the receiving end of a slow link. Security policies and administrative templates are always loaded, no matter what the link speed. However, group policies such as login scripts, software pushes, and folder redirection are not pushed to the user who is accessing GP via a slow link. This can be problematic for sites that don't have local domain controllers and receive authentication across a slow WAN link.

If you have unreliable or saturated bandwidth, you might want to change the configuration of what is considered a slow link in the site or disable slow link detection completely.

Determining Slow Link Speed

By default, a slow link has an average ping time of greater than 32ms using 2,048 byte packets, or a time greater than 500Kbps. Microsoft uses the following formula to convert ping times to Kbps. The formula is as follows:

16,000/ping = Kbps

Therefore, the default value of a 32ms ping times equals the following when the formula is applied:

16,000/32ms = 500Kbps

To determine whether a site has a slow link, perform a ping from that location to the nearest DC it would use to authenticate and obtain its group policy. Use the following format for the ping command to make sure the test packed is a 2,048Kb packet:

ping l 2,048 servername

where servername is the closest domain controller.

The time it takes to return the ping will show if the link is more than 500Kpbs and thus a slow link subject to the slow link restrictions.

Configuring a Unique Slow Link Speed

To override Microsoft's default definition of a slow link, change slow link behavior, or otherwise change slow link configuration, go to the following areas in Group Policy:

  • Computer Configuration, Administrative Templates, System, Group Policy, Group Policy Slow Link Detection Properties. (Set to 0 to disable slow link detection or set a unique slow link time period.)

  • User Configuration, Administrative Templates, System, Group Policy, Group Policy Slow Link Detection. (Set to 0 to disable slow link detection or set a unique slow link time period.)

Group Policy also allows for changing the behavior of processes such as scripts, folder redirection, software installation, and security when slow links are in effect. These can be changed by choosing Computer Configuration, Administrative Templates, System, Group Policy, and editing the Policy Processing group policies.


Using Tools to Make Things Go Faster

You can take specific steps to make group policy application faster for users as well as make it easier on system administrators to administer the group policies.


Linking Group Policies

If a group policy will be applied to many different locations, you should create the policy once and assign the permissions, and then link the policy to the other locations rather than creating the policy multiple times. Linking the policies achieves the following objectives:

  • Creates fewer group policies in SYSVOL. This allows for quicker domain controller promotion and less replication traffic.

  • A single point of change for the GPO. If the GPO is changed, the change is applied to all the locations where the GPO is linked.

  • A single point of change for permissions. When permissions are configured or changed in one location on a linked GPO, the permissions are applied universally to each place where the GPO is linked.

Configuring the Group Policy Snap-in

When a site administrator opens the GPMC or the group policy through ADUC, the domain controller that is used to make group policy changes and process the changes is, by default, the only one that holds the FSMO role of PDC Emulator Operations Master. Although this was configured to help eliminate replication problems, this can cause frustration and delays for remote administrators making changes to a group policy under their control by having to wait for the changes to replicate from the remote PDC Emulator DC. To force the GPMC and Group Policy snap-in to use the most available domain controller, enable the following group policy: User Configuration, Administrative Templates, System, Group Policy, Group Policy Domain Controller Selection.

Choose Use Any Available Domain Controller or Inherit From Active Directory Snap-ins to use the DC to which the open snap-in is connected. The default that points to the PDC Emulator is the choice to Use the Primary Domain Controller. Figure 21.3 shows the domain controller selection of Inherit From Active Directory Snap-ins.

Figure 21.3. Configuring the domain controller selection.

Disabling Configuration Settings

To speed up login and boot times for users, it is recommended that if the entire User Configuration or Computer Configuration section is not being used in a GPO, the unused section should be disabled for the GPO. This expedites the user login time or the computer boot time, as the disabled sections aren't parsed upon boot or login.

To disable configuration settings using Active Directory Users and Computers:

1. | Click on a group policy.
2. | Click Properties.
3. | Go to the General tab.
4. | Click on either Disable Computer Configuration Settings or Disable User Configuration Settingswhichever section is not being utilized.

To disable configuration settings using the GPMC:

1. | Click on the group policy in GPMC.
2. | Click on the Details tab.
3. | Click on the drop-down box at the bottom of the Details tab.
4. | Choose Computer Configuration Settings Disabled or User Configuration Settings Disabled, depending on which portion needs to be disabled.

Viewing Group Policy Using the Show Configured Policies Only

Searching through Administrative Templates for a particular group policy that is configured can be very time consuming. However, ADUC and the GPMC can be configured easily to show only the Administrative Templates objects that are configured. It removes from the view any policies or policy folders that don't have policies configured within them, making it much easier and faster to find a specific configured policy. Figure 21.4 shows what a GPO looks like when viewed using the Show Configured Policies Only.

Figure 21.4. Standard Group Policy Object screen.

[View full size image]

To view only the configured policies while using ADUC or the GMPC:

1.
Open ADUC or GPMC.

2.
Edit a group policy to view.

3.
Click on Computer Configuration/Administrative Template or User Configuration/Administrative Template.

4.
Right-click on the Administrative Templates section and choose View, Filtering.

5.
Select the Only Show Configured Policy Settings option, as shown in Figure 21.5.

Figure 21.5. Selecting the Configured Policy Settings option in GPMC.

[View full size image]

Deleting Orphaned Group Policies

When a GPO is deleted, you have two choices: Delete the link or delete the entire policy. Each option carries certain consequences.

If the Group Policy Object should be removed from being applied at that location but it is or will still be applied elsewhere, choose to remove just the link. This leaves it in the available group policy list for future use. If the GPO will not be used elsewhere or ever again, delete the object permanently. This removes the policy from SYSVOL permanently and removes it from Active Directory.

If the policy won't ever be used again and the policy isn't fully deleted, this results in the Group Policy being left unused in the SYSVOL area on each domain controller. This adds unnecessarily to the time it takes to create a new domain controller, and increases replication time and storage space on the domain controller.

If you are using ADUC to access Group Policy, Windows 2003 presents you with two choices when trying to delete a group policy: Remove the Link From the List or Remove the Link and Delete the Group Policy Object Permanently.

If you are using the GPMC, delete the link by right-clicking on the Group Policy Object under the object to which it is applied. A pop-up box appears that asks, "Do you want to delete this link? This will not delete the GPO itself," thereby leaving the GPO available for linking elsewhere. To delete the link, click OK in the box.

To fully delete the GPO, click on the folder in GPMC titled Group Policy Objects. Right-click the GPO and choose Delete. A pop-up box appears asking "Do you want to delete this GPO and all links to it in the domain? This will not delete links in other domains." To complete the deletion, click OK.

Note

Be sure to check whether the GPO is linked elsewhere in the domain before deleting the object completely. This can be done through the GPMC and ADUC.


Automating Software Installations

A major benefit of Group Policy is the capability to push software packages to computers and users. Although other applications (such as SMS) might provide a better method for distributing software (because they are probably more sophisticated and have better reporting capabilities), Group Policy can be used to push software. An added bonus is that it comes free with the default installation of Windows Server 2003.

Determining Whether a Push Was Successful

Without additional software, it is not possible to determine whether a software package was pushed successfully from a single centralized location. All evidence of software pushes is seen locally on the client machines. On the local machines, there are three areas to check to determine whether a software installation was successful:

  • MSI Installer events and Application Management events are written into the Application event logs

  • While the machine is booting, the Installing Managed Software dialog box will appear while the software is installing and before the user is presented with the login screen. Upon subsequent reboots, the message does not appear.

  • On the local machine, view Add/Remove Programs to see whether the software package is listed.


Enhancing Manageability with Group Policy Management Console

GPMC is the new tool used for configuring and using Group Policy with Windows 2003. After it is installed, the choice to use AD Users and Computers to access and configure Group Policy is removed from the local computer.

Note

If the Group Policy tab is accessed via ADUC, you are presented with a tab that says, "You have installed the Group Policy Snap-in so this tab is no longer used" and an Open button that opens the GPMC directly.

The GPMC must be installed on Windows Server 2003 or Windows XP. The GPMC.msi package can be downloaded from the http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx Web site. Once installed, it can be found by choosing Start, All Programs, Administrative Tools, Group Policy Management.

Tip

The GPMC can be used to manage Windows 2000 Group Policy as well, but must be run on a Windows XP machine. The GPMC provides many useful features; some of the most useful will be covered in the following section.

GPO Operations: Backup, Restore, Copy, and Import

A crucial improvement in Group Policy is the ability to back up (or export) the data to a file. Then you can restore the Group Policy data into the same location. Note that the backup only backs up data specific to that GP itself. Other Active Directory Objects that can be linked to GPOs such as individual WMI filters (although the WMI links are backed up and restored) and IP Security policies are not backed up, because of complications with restores. Note also that performing a restore actually restores the original GUID of the GPO. This is useful when replacing a misconfigured GPO, or especially one that was deleted.

The importing functionality allows for the importation of exported GPO data into a different location than the one from which it was exported, even to one with which no trust exists. Imports can be done in different domains, across forests, or within the same domain. This is most useful to move a GPO from a test lab into production without having to manually create what was done in the test lab, or, conversely, to update a test lab with the most current GPOs in production.

Copying GPOs is a very useful tool, as well. If you have configured a complex GP on a certain OU and want to duplicate the GPO(s) on other OUs, you need only copy the GPO and a new GPO is automatically created with the copy process. This new GPO can then be placed in the new location. You don't need to re-create the GPOs manually. This is quicker and also eliminates the possibilities of mistakes. Note however, that the data isn't saved to a file as it is in the backup or export of the GPO data. Trusts must be in effect for cross-domain or forest copies, or the Stored User Names and Passwords utility can be used if no trust exists. Note that copying a GPO requires creation of GPO rights in the target area as well as read access to the source GPO.

Migrating Tables

During a cross-domain or forest restore or copy operation, it might not be the best method to import all the exact configuration settings that exist in the backed-up GPO to the new area. For this purpose, migration tables are useful. A migration table can be used to convert values from a source to values that apply in the new target location or destination. The source and destination mappings can be changed to accommodate any differences in configuration between the two.

Note

When using a migration table, the security principles being specified in the destination areas of the mapping table must already exist to import the backed-up GPO.

Supporting Group Policy Management Across Forests

The GPMC enables you to easily view and configure Group Policy in multiple forests and domains. The default view shows multiple forests, and you can configure which forests and domains to view and administer from the GPMC. It is not possible to link a GPO from a domain in a forest to another domain in another forest. However, it is possible to configure group policies to reference servers in another forest.

By default, a forest can only be managed if a two-way trust exists between it and the forest of the administrator. You can configure it to work with only a one-way trust or no trust at all by choosing View, Options, clicking the General tab, and unchecking Enable Trust Delegation.

If you are supporting Group Policy in a forest with which you don't have a trust, you will need to use the Stored User Names and Password tool to access the other forest. Find the Stored User Names and Password tool by choosing Start, Control Panel, User Accounts, Advanced, Manage Passwords in Windows XP or Start, Control Panel, Stored User Names & Passwords in Windows Server 2003. When the Stored User Names and Password tool appears, you will see a screen similar to Figure 21.6.

Figure 21.6. The Stored User Names and Password tool.

HTML Reporting Functionality and the Settings Tab

The Settings tab is a very useful area in the GPMC. You can use it to view the HTML reports on the GPO. These HTML reports state what is configured in the individual GPO. It provides an area to see all the settings, allows for looking easily at the descriptions (the "explain" sections) of the selected objects, and lets you condense and expand the details of the report by clicking on Show All. Additionally, the reports can be saved or printed.

Linking WMI Filters

Linking WMI filters enables you to apply group policies and establish their scopes based on attributes of target computers. You can do this by using the WMI filters to query the WMI settings of the target computers for true/false, and then applying group policies based on the true/false WMI queries. A "false" on the target computer results in the GPO not being applied. Conversely, a "true" results in the application of the GPO.

Because WMI filters are separate from GPOs, they must be linked to GPOs in the GPO Scope tab to function properly. Only one WMI filter can be applied to each GPO. Additionally, WMI filters will only work on Windows XP and later workstations, not on pre-Windows 2000 or nonMicrosoft operating systems.

Searching the GPMC for Group Policies

The GPMC enables you to search for specific group policies or data within the GPOs. Data such as permissions, GPO name, linked WMI filters, user configuration contents (what is configured), computer configuration contents, and GPO GUID can be searched for using the granular searching functionality in the GPMC.


Using Resultant Set of Policies in GPMC

Resultant Set of Policies (RSoP) is part of the GPMC that provides a GUI interface that enables you to test a policy implementation prior to rolling it out in production and also enables you to view what policies a user or computer is actually receiving.

Group Policy Modeling Using Resultant Set of Policy

RSoP planning mode enables you to simulate the deployment of a specified group policy, check the results, change, and then test the deployment again. This is very helpful in a lab environment where you can create and test a new set of policies. After RSoP shows that the GPO is correct, you can then use the backup functionality to back up the GPO configuration and import it into production.

To run RSoP in simulation mode, right-click on Group Policy Modeling in the forest that will be simulated, and choose Group Policy Modeling Wizard. The wizard allows for inputting the possibility of slow links, Loopback configuration, and WMI filters as well as other configuration choices. Each modeling is presented in its own report as a subnode under the Group Policy Modeling node.

Using RSoP Logging Mode to Discover Applied Policies

RSoP in logging mode enables you to view what exact policies a user or computer might be receiving. It shows in a readable format what polices are enforced, where conflicts exist, and what different policies are being applied to the user/computer. It can be run either on the local computer or on a remote computer by choosing the proper options in the wizard. To run RSoP in logging mode, right-click on Group Policy Results in the GPMC, and then click on the Group Policy Modeling Wizard selection and follow the wizard that appears.


Understanding Windows Management Instrumentation

Windows Management Instrumentation (WMI) is Microsoft's implementation of Webbased Enterprise Management (WBEM) that is intended to create a standard for the management of the Windows networking environment. Although Microsoft has various initiatives relative to enterprise network management, WMI in the context of group policies typically refers to two things: one is the use of WMI scripts, and the other is the use of WMI filtering.

Using WMI Scripting

Although Group Policy can automate a number of tasks in a Windows networking environment, there are many things that it cannot do. When a group policy cannot be used, typically a WMI script can be used to complete the task. Such tasks include the following:

  • Moving files from one folder to another on the network

  • Deleting a file or list of files from the network

  • Automating the process of installing a new network printer

  • Automating the process of adding a user account and user profile to the network

Typically, when a network administrator hears the term scripting, he immediately begins to think about Visual Basic programming and application coding. However, if you can cut, paste, copy, and edit text information, you can effectively use WMI scripts for group policies.

Microsoft provides hundreds of predefined scripts that can be copied and pasted into a group policy. In the Windows Script Development Center at http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001169, there are samples of scripts that can be copied, pasted, and then edited to create fully functional scripts. As an example, the following script adds domain users into groups. By simply editing "fabrikam" with the name of your domain, and editing the cn (common names) and ou (organization units) names and OUs in your organization, you can use this script to automate a process that might otherwise take you a few seconds to do manually. A few seconds multiplied by hundreds of adds, moves, and changes to a network can add up to significant time savings over the course of a month or year.

Const ADS_PROPERTY_APPEND = 3
Set objGroup = GetObject _
  ("LDAP://cn=Sea-Users,cn=Users,dc=NA,dc=fabrikam,dc=com")
objGroup.PutEx ADS_PROPERTY_APPEND, "member", _
    Array("cn=Scientists,ou=R&D,dc=NA,dc=fabrikam,dc=com", _
      "cn=Executives,ou=Management,dc=NA,dc=fabrikam,dc=com", _
      "cn=MyerKen,ou=Management,dc=NA,dc=fabrikam,dc=com")
objGroup.SetInfo

Some organizations have extended scripting to automate an employee account creation process. Rather than manually creating a user, manually adding the user into groups, manually creating an email address, a phone number, and other user information, a script can be linked to an OU such that every time a user is created in an OU, the properties for that user are automatically created and associated to the user.

Using WMI Filters

WMI filters allow an administrator to specify a WMI-based query to filter the effect of a Group Policy Object in the WMI object database. As an example, a WMI filter can look for certain group membership assignments for a user, and based on the user's group membership, apply a script as appropriate.

Adding a New WMI Filter to a Group Policy Object

To add or delete a new WMI filter to a Group Policy Object, perform the following steps:

1. | Open Active Directory Users and Computers.
2. | Right-click the domain or OU for which you want to set a group policy.
3. | Click Properties and then click the Group Policy tab.
4. | Click an entry in the Group Policy Object links and then click Properties.
5. | Click the WMI Filter tab.
6. | Click This Filter and then click Browse/Manage.
7. | Click Advanced.
8. | Click on New to add information about any new filters or click Delete to remove a filter. Then click OK.
Importing to and Exporting from a Group Policy Object

To import to or export from a Group Policy Object, perform these steps:

1. | Open Active Directory Users and Computers.
2. | Right-click the domain or OU for which you want to set a group policy.
3. | Click Properties and then click the Group Policy tab.
4. | Click an entry in the Group Policy Object links and then click Properties.
5. | Click the WMI Filter tab.
6. | Click This Filter and then click Browse/Manage.
7. | Click Advanced. Then click Import to import, or click the filter in the list you want to export and click Export. Finally, click OK.

When you're importing, select an MOF file that contains the WMI filter or filters you want to import.


Maximizing Security with Group Policy

Using Group Policy is an excellent method to increase security in an organization. It can be used for everything from setting domain-level security policies that apply to every user and computer (such as password length, complexity, and lockout values) to applying security measures to specific groups of specialized users with specific needs.

For example, you might be managing a group of users who need to be highly managed. They need to have a very secure environment implemented on their workstations and logins, an environment that they cannot get aroundenvironments where they cannot edit the Registry, add software, change permissions, stop or start services, or view the event logs. Applying a specific, highly secure Group Policy Object to that group would accomplish this.

Additionally, the same policy could be applied easily using a template across various OUs and groups of users. If you are managing a group whose members need a great many rights and the capability to manipulate their workstationssuch as the ability to install software, change settings, edit the Registry, and change driversapplying more permissive group policies to that group could accomplish that as well.

Predefined Security Templates

Microsoft provides predefined security templates for Group Policy, based on the type of users and environment needed (highly secure workstations and servers, secure workstations and servers). These templates can be imported into Group Policy Objects, where they can then either be implemented as is, or changed as the environment requires. However they are used, they are a great security starting point with which to obtain a base level of security. The templates can be used to configure settings such as account policies, event log settings, local policies, system service settings, Registry permissions, and file and folder permissions.

The following list describes the security templates that can be added after installation:

  • Secure There are two secure templates, one for workstations and one for domain controllers. The workstation is called Securews.inf and the domain controller is called Securedc.inf.

  • Highly secure The highly secure template (hisecws.inf and hisecdc.inf) goes beyond the secure template and applies even more restrictive and secure policy configurations. It is also available for both domain controllers and workstations.

  • System Root Security This template (Rootsec.inf) provides a default set of secure root permissions for a root C drive. It is useful if the permissions have been changed and need to be returned to a secure default setting. With regard to child objects, it only propagates the security changes to child objects that inherit permissions; it does not overwrite explicit permissions on child objects.

  • Compatible This template (Compatws.inf) should only be applied to workstations. It changes the security settings for members of the users group by configuring a basic set of Registry and file permissions that allows most Microsoft software to function properly but securely. It also removes any members of the Power Users group.

Required Default Domain Group Policy Settings

As stated earlier, Account Policy settings applied at the OU level affect the local SAM database, not Active Directory accounts. The Account Policy settings must be applied on the Default Domain Policy to affect Active Directory accounts. The Account Policy settings that must be configured in the Default Domain Policy to affect the accounts in AD are located in the following areas in Group Policy:

  • Password Policy

  • Account Lockout Policy

  • Kerberos Policy

Restricted Groups: Assigning Local Groups Through GP

Restricted groups can be used to set the membership of local groups such as Administrators and Power Users on servers and workstations. However, this cannot be applied to domain controllers because they don't have local groups. Restricted groups can be useful in extremely secure environments where the addition of users to local groups on workstations or servers would be problematic, or if group membership were accidentally changed. Assigning local groups would automatically remove the incorrect group membership and replace it with the membership specified in Group Policy.

For example, you can create an OU that is used only to replace local workstation administrative group membership that was changed. You would create a local group, and if the workstation were discovered to have incorrect group membership, the workstation would be moved to the OU. The next time the workstation was rebooted, the incorrect group membership would be removed and the proper group added. The computer could then be moved back to the proper location.

To create a restricted group:

1.
Edit Group Policy.

2.
Choose Computer Configuration, Windows Settings, Security Settings, Restricted Groups.

3.
Right-click on Restricted Groups and select Add Group.

4.
Click Browse.

5.
Type the name of the group and click OK.

6.
Click OK again on the Add Group dialog box.

7.
On the top section labeled Members Of This Group, click the Add button.

8.
Click Browse.

9.
Type in or browse for the desired users or groups that should be members of the new local restricted group. After adding members to the group, the dialog box will look similar to Figure 21.7.

Figure 21.7. Members added to a restricted group.

[View full size image]

10.
Click OK to finish and close the dialog box.


Getting the Most Out of Folder Redirection

In the Group Policy Object Editor, you can use Folder Redirection to redirect certain special folders to network locations. Special folders are those folders, such as My Documents, that are located under Documents and Settings. Folder Redirection is located under User Configuration in the console tree of the Group Policy Object Editor. Several basic options for Folder Redirection will be discussed in this section. For each basic option, an advanced version of that option is available. The advanced version provides for finer control by allowing redirection that is based on security group membership.

Creating a Folder for Each User Under the Root Path

Rather than having to type a Universal Naming Convention (UNC) path, such as \\server\share\%username%\MyDocuments, you can simply type the path to the share, such as \\server\share, and Folder Redirection automatically appends the username and folder name when the policy is applied. With Folder Redirection in place, you can minimize errors and spelling mistakes from constantly retyping environment variables and share names.

To redirect special folders to the root directory, perform the following steps:

1. | Open a Group Policy Object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
2. | In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.
3. | Right-click the special folder that you want to redirect (for example, Desktop or My Documents) and then click Properties.
4. | On the Target tab, in Settings, click Basic - Redirect Everyone's Folder to the Same Location.
5. | Under Target Folder Location, click Create a Folder for Each User Under the Root Path.
6. | In Root Path, type a Universal Naming Convention path (for example, \\servername\sharename) and then click OK.
7. | In the Properties page for the special folder, click OK.

Redirecting to Home Directory (My Documents)

A new feature provided with Windows Server 2003, the redirect option allows you to redirect a user's My Documents folder to the user's home directory. This option is intended only for organizations that have an existing deployment of home directories and that want to maintain compatibility with their existing home directory environment. Use this option only if you have already deployed home directories in your organization.

To redirect My Documents to the home directory, follow these steps:

1. | Open a Group Policy Object that is linked to the site, domain, or organizational unit that contains the users whose My Documents folders you want to redirect.
2. | In the console tree, double-click Folder Redirection to display My Documents.
3. | Right-click My Documents and then click Properties.
4. | On the Target tab, in Settings, click Basic - Redirect Everyone's Folder to the Same Location.
5. | Under Target Folder Location, click Redirect to the User's Home Directory and then click OK.

Note

Users must have the home directory property set correctly on their user object in Active Directory. The client computer finds the path for the user's home directory from the user object in Active Directory at login time. Users who are affected by Folder Redirection policy must have this path set correctly; otherwise, folder redirection will fail.

Redirecting to a Special Path

With the option to redirect folders to a special path, you can redirect users' folders to an alternative local drive or partition, or they can enter unusual configurations that are not anticipated by the new Folder Redirection user interface. Functionally, this works in exactly the same way as the Windows 2000 Folder Redirection user interface.

To redirect special folders to a specific path, follow these steps:

1. | Open a Group Policy Object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
2. | In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.
3. | Right-click the special folder that you want to redirect (for example, Desktop or My Documents) and then click Properties.
4. | On the Target tab, in Settings, click Basic - Redirect Everyone's Folder to the Same Location.
5. | Under Target Folder Location, click Redirect to the Following Location.
6. | In Root Path, type a UNC path (for example, \\server\share). You can also use a locally valid path (for example, C:\somefolder). Then click OK to continue.

Redirecting to the Local User Profile

With the option to redirect to the local user profile, you can redirect the selected folder back to the default location in the local user profilefor example, %userprofile%\ <Folder Name>.

To redirect special folders to the local profile location, follow these steps:

1.
Open a Group Policy Object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.

2.
In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.

3.
Right-click the special folder that you want to redirect (for example, Desktop or My Documents) and then click Properties.

4.
On the Target tab, in Settings, click Basic - Redirect Everyone's Folder to the Same Location, similar to what is shown in Figure 21.8.

Figure 21.8. Redirecting folders.

5.
Under Target Folder Location, click Redirect to the Local User Profile Location and then click OK.

Note

In the Properties page for a special folder, changing the setting to Not Configured does not cause the special folder to be redirected back to its default location. The Not Configured setting simply leaves the redirected folder where it is.

Using Roaming Profiles

Roaming profiles enable users to access their data, including redirected folders, wherever they log in. Items such as data on their desktop, application configuration, printers, and display options follow the users wherever they log in. The roaming profiles are stored on the local workstation(s) where the user logs in and also in a central repository on a server that can be accessed from any location from which the user might log in. This increases user productivity by giving users the tools and data they need, no matter where they are logging in. However, it does leave a copy of the user data, including offline files if configured, in every location where the user has logged in.

Warning

Although the leftover roaming profiles left on the workstations and offline files are protected by ACLs, local administrators can gain access to the files on the local workstation. This should be a consideration when deciding whether to use the roaming profiles and offline files/folder redirection.


Other Useful Tools for Managing Group Policies

Microsoft provides additional tools for managing group policies and the File Replication Service, above and beyond ADUC and GPMC. Some are loaded automatically with Windows 2003 Server and others can be found on the Microsoft Web site or with the Windows 2003 Resource Kit.

Using the gpupdate.exe Tool

The gpupdate.exe utility comes with Windows 2003 and replaces the Windows 2000 Server secedit/refreshpolicy command-line utility. When run, it refreshes the computer policy or user policy, both locally and AD-based, including security settings. This eliminates the need to have the user reboot or log out/in to receive the new policy changes immediately. The syntax is as follows:

Gpupdate [/target:{computer | user}] [/force] [/wait:Value] [/logoff] [/boot]

For more information on the syntax commands, type the following at the command prompt to access help:

Gpudate /?

Using the gpresult.exe Tool

gpresult.exe is a free utility from Microsoft that comes with the Server Resource Kit. It's a small program that has to be installed before use. It must be run via a command line on the machine that is being investigated. The gpresult.exe tool will discover where the computer and the logged-in user are receiving their Group Policy and what policies are applied to them. Although a great deal of the information output by the gpresult.exe tool is available in other areas and using other tools, it is convenient to have it all displayed in one place.

Using the Group Policy Monitor Tool

gpmonitor.exe is the Group Policy Monitor tool. It is used to gather information collected during GP refresh intervals and send the data to a specified central location. There, the tool can be used to analyze the data, as well. gpmonitor.exe is available in the Windows Server 2003 Deployment Kit.

Using the GPOTool.exe Tool

GPOTool.exe should be used for troubleshooting Group Policy issues in domains with more than one domain controller or across domains. The tool scours all the domain controllers in a domain or across domains and checks for consistency between the group policies located in the SYSVOL share on each domain controller and reports on what it finds. It also checks the validity of the group policies on all domain controllers, checks on object replication, and displays detailed information about the GPOs. GPOTool.exe is available with the Microsoft Windows 2000 Server Resource Kit and is also available for downloading on Microsoft's Web site.

Using the FRSDiag.exe Tool

FRS replication is the replication service that is used to replicate Group Policy Objects between domain controllers. It can be very difficult to troubleshoot, due in no small part to the troubleshooting tools that were available for use up to that time. However, Microsoft now has an excellent new tool called FRSDiag that provides a GUI interface through which you can run tests easily to analyze FRS replication. You can choose to look at single or multiple domain controllers at a time, check their event logs for errors, run NTFRSUTL options, run REPADMIN /showreps and REPADMIN /showconn, and run many of the previously available FRS tools. However, the results are much clearer and easier to understand when output to the GUI interface. When the tool is configured to output the results to a screen, it lists any DCs with failures in red and any successes in green. The output can also be put into cab files. FRSDiag.exe can be downloaded from http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx.

A highly useful test available within FRSDiag is the Canary File Tracer. The Canary File Tracer can be configured to check the SYSVOL\domain name\policies directory (or any directory specified in the Share Root text area) for the correct number of folders or files. For example, if domain controllers cannot replicate group policies successfully and have a different number of policy folders present in their SYSVOL\domain_name\policies folder, this tool will, in minutes, check the number of folders on each domain controller across the domain to see whether they match across the domain controllers and output this data to the screen. It even tells how many policies above or below the target number the domain controller is off by. To do this, follow these steps:

1. | On the main screen, in the Target Server area, choose all the domain controllers in the domain.
2. | In File Output, choose None.
3. | Choose Tools, Canary File Tracer.
4. | In the share root area, type the following: domain_name\policies\*.*
5. | In the Expected Number of Hits box, type the number of folders in the policies container (for example, 135).
6. | Click the Go button.

The Canary File Tracer will then output the data to the screen, showing the results of the tests. Obviously, the Canary File Tracer can be used to troubleshoot other issues and search for other files and folders as well. It's not just limited to the search capabilities listed previously.

Figure 21.9 shows the configuration options for the Canary File Tracer.

Figure 21.9. The Canary File Tracer configuration.

Note

This tool also works for Windows 2000 servers; however, .NET Framework v. 1.1 must be installed for it to function.

Using the Sonar.exe Tool

Sonar.exe can be downloaded from http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx. It provides a GUI interface that enables you to check the FRS replication health of all domain controllers in the domain, which can help with troubleshooting Group Policy replication problems. Sonar can be configured to poll the domain controllers at different intervals for FRS health and will output the results, such as backlogged files waiting to be replicated, downed FRS services, and other error states to the GUI screen. Sonar is also a useful tool for monitoring DFS health because it uses FRS as well.


Using Administrative Templates

Administrative templates are installed by default in Group Policy. They are changes to the Registry of Windows 2000 and XP machines. In the Registry, the changes are stored in the \HKEY_LOCAL_MACHINE (HKLM) hive for computer policies and HKEY_CURRENT_USER (HKCU) hive for user policies and then in the following hives under HKLM or HKCU:

\SOFTWARE\POLICIES \SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES

By default, standard users do not have the right to change Registry entries in these keys and change the Group Policy behavior because the keys are protected by ACLs.

You don't have to be limited by the default installed Administrative Templates. Microsoft provides additional templates to enhance the choices available for use with Group Policy, and custom Administration Templates can be written and imported to add custom keys and Group Policy options.

Policies Versus Preference

Both preferences and policies are controlled through the Registry. Preferences are changes to the Registry that the user has control over and are not found in the Registry keys listed previously. These are options, such as wallpaper or screensavers. Policies are changes to the Registry in the keys listed previously, which are protected by ACLs. Although Group Policy can overrule preferences, the basic user would normally have access to change the Registry settings through the operating system or an application. The policy does not overwrite the preference keys, and if the policy is removed, the preferences will return. The preference settings remain in effect until they are removed or changed via the Registry.

It is a good idea to use policies rather than preferences when you want to control a certain aspect of an application or want something the user accesses to remain static. You can disable users from being able to change the appearance, configuration, or functionality of the item. For those items, using administrative templates is your best answer.

Using Microsoft Add-on GP Templates

Microsoft provides additional administrative templates for use with Microsoft Officeusually as part of the Office Resource Kits. Installing these administrative templates provides you with many more Group Policy options for each Microsoft Office product.


Modifying Administrative Templates

With a baseline understanding of how Group Policy functions in a Windows Active Directory Domain environment, Microsoft Exchange 2003 administrators can look at how Group Policy, GPOs, and templates can be leveraged to enhance the ability to manage applications like Microsoft Outlook 2003 in the enterprise. Working with predefined Group Policy templates available from Microsoft, administrators can now manage areas and control access and changes, ranging from restrictions and preventing configuration modifications to controlling the look and feel that affects the overall user experience when working with application software.

In this section, we will review the tools and options for managing an application such as the Microsoft Outlook 2003 client software, specifically using Group Policy and predefined templates. We will also explore the options available with Group Policy when deploying and working with the Outlook client, Outlook Group Policy templates, and the steps for configuring administration privileges for managing the Exchange client through Group Policy.

Outlook Client Policy Options

To further enhance the management functionality when working with an application like the Outlook 2003 software, the Office Resource Kit (ORK) provides a predefined template for managing Outlook clients using the Group Policy functionality of Windows domains.

Called Outlk11.adm, this template enables administrators to centrally manage and configure many of the preferences and security functions normally required to be configured at each individual Outlook client. Using Outlk11.adm, administrators can fully manage and configure the following areas:

  • Outlook preferences The preferences options available with the security templates can be defined in the same manner as using the Options tab available in the Tools menu of the Outlook client. When defining preferences, administrators can control the standard look and feel of each component available with Outlook. Options include areas for enforcing items such as spell-check and email format, calendar views, and contact options.

  • Exchange settings Configuration items, such as profile configurations and auto archiving, can now be centrally configured.

  • SharePoint Portal Server settings In addition to the Outlook client settings, using the templates enables administrators to configure access to SharePoint Portal Server resources through the Outlook client.

Adding the Outlook Administrative Template

Because the additional administrative templates are not installed by default when Windows Server 2003 is installed, administrators must download or install the Outlook administrative template manually. Available on the ORK, Outlk11.adm is placed on the local drive of the systems where the ORK is installed.

To begin setting up the Outlook administrative template, start by installing the GPMC on the domain controller where the policy will be administered. Next, install the Microsoft ORK on a system where the template can be accessed from a domain controller for import into the Domain Group Policy.

Tip

The Office 2003 Resource Kit can be downloaded from the Microsoft Office Web site at http://www.microsoft.com/downloads.

After the ORK is installed, the Outlk11.adm file is automatically extracted and placed in the C:\Windows\Inf directory (where C: represents the drive where the Windows installation resides) on the local system drive where the ORK was installed.

To import the Outlook security template Outlk11.adm into the Domain Group Policy using the Group Policy Management Tool, use the following steps:

Tip

When importing the Outlk11.adm security template, it is best to import the template to the Default Domain Group Policy.

1.
From a domain controller in the domain where the policy will be applied, open the Group Policy snap-in by selecting Start, All Programs, Administrative Tools, Group Policy Management.

2.
Select the Default Domain Policy where Outlk11.adm will be imported to, as shown in Figure 21.10.

Figure 21.10. Select the location in the Group Policy Management Console.

[View full size image]

3.
From the Action menu select Edit; this opens the Group Policy Object Editor window.

4.
On the Group Policy Object Editor, select Administrative Templates under the User Configuration option and right-click to choose Add/Remove Templates, as shown in Figure 21.11.

Figure 21.11. Select Add/Remove Templates in the Group Policy Object Editor.

[View full size image]

5.
From the Add/Remove Templates dialog box, click the Add button.

6.
Navigate to the location where Outlk11.adm was placed, as noted in step 2. Select the template to import OUTLK11.ADM and click the Open button.

7.
Ensure that the OUTLK11 template has added the Add/Remove Templates dialog box, and click Close to continue.

You should now see the Microsoft Outlook 2003 template under the Administrative Templates folder in the Group Policy Editor.

Assigning Group Policy Delegates

Although Group Policy has traditionally been the management task of Windows domain administrators, with delegation, permissions can be assigned to additional resources and accounts to manage Microsoft Outlook clients. Using the Delegation Wizard of the GPMC, accounts can assign and delegate rights to add, modify, and delete Group Policy Objects.

It is important to delegate the proper rights for administrators to manipulate Outlook 2003 group policies. Using the delegation option of the GPMC, administrators can assign a very small group of users permission to edit Outlook policies at the domain level. To enhance this functionality, it is also possible to allow diverse groups of administrators to configure group policies at lower levels of the Active Directory domain tree.

When assigning permissions, administrators can delegate the following rights:

  • Create GPO

  • Create WMI filters

  • Permissions on WMI filters

  • Permissions to read, edit, and so forth an individual GPO

  • Permissions on individual locations to which the GPO is linked (SOM)

How to Delegate Rights over GPOs

To understand the steps required to assign rights over GPOs, let's look at the following scenario to assign one Active Directory account permission at the domain level. The rights that will be assigned to the account will be the Edit Group Policy Objects Only permissions.

To begin, open the GPMC by selecting Start, All Programs, Administrative Tool, Group Policy Management. Then follow these steps:

1.
On the GPMC, select Domain Folder, Your Domain, Group Policy Objects, Default Domain Policy.

2.
Select the Delegation tab in the right pane of the Domain Group Policy Object.

3.
To add an account, select the Add button, enter the name of the account to be added, and click the OK button.

4.
Select the rights to be assigned to the account by selecting the permission Edit in the drop-down box, as shown in Figure 21.12; select OK to continue.

Figure 21.12. Add Group or User permissions.

The account has now been assigned rights to edit the domain-level GPO. Review the information and test settings to ensure that the permissions have been applied correctly.

Managing Group Policy Configurations

Through Group Policy, Outlook configuration settings can be configured and applied differently depending on how the GPO is applied.

Exchange administrators can not only centrally manage one group of Outlook clients, but they can configure and apply a completely different set of options enforced on a different group or OU in the domain by following these steps:

1. | Open the GPMC and select the organizational unit to which to apply the GPO.
2. | Select Action from the menu bar and select Link An Existing GPO.
3. | From the Select GPO dialog box, choose the domain policy and click OK to link the domain policy to the desired organizational unit.

Tip

When linking the GPOs, access to the GPMC can be obtained through the Active Directory Users and Computers (ADUC) snap-in. Select the properties of the domain you are working with and select the Group Policy tab.

Defining Baseline Outlook Preferences

One option that group policies enable organizations to accomplish when managing an application like the Outlook client is the ability to design, develop, and implement a baseline configuration for every client configuration in use. Often, this was not an option because of the exhaustive amount of administration involved, along with the inability to secure configurations from modification.

With the option of standardizing configuration for all Outlook client systems, administrators must wonder which options can be configured to improve the productivity and functionality of the network client for every user. Using the Group Policy Object settings to define simple Outlook configuration settingssuch as Saving Sent Items, Spell Checking Messages Before Sending, and Auto Archive Settingscan not only improve the functionality of the Outlook client, but can also reduce administrative management overhead when supporting workstations and users.

Email Options

Some of the most useful email options available when configuring settings using Group Policy include the following:

  • HTML/Microsoft Word message format The most enhanced of all Outlook email options is the HTML/Microsoft Word format. This option can be enabled to provide a robust email editor.

  • Junk Email Filtering Enabling the Junk Email Filtering option allows the configuration of filtering email at the client level.

  • OST/PST Creation Disabling or enabling the OST and PST Creation options can provide control of network traffic and local system disk space utilization.

  • Empty Deleted Items Folder Controls the total amount of space each user mailbox can have, helping control storage limits; administrators can enable this option.

  • Auto Archive One area often requiring administrative overhead, the Auto Archive option can now be toggled via GPO settings.

  • Email Accounts Using this option, users can be prevented from adding additional account types.

Calendar Options

In addition to the email options available, the following calendar options can be defined to establish a base functionality for all Domain Outlook users:

  • Reminders Display Options Calendar reminders can be disabled and enabled.

  • Working Hours and Work Week These options can be defined and set for all calendar views.

Contact Options

One interesting setting is the option in the Outlook security template for contacts. Administrators can define how each contact will be filed and displayed. For example, the Display Name can be set as First, [Middle], Last Name, and the File As option for the contact as Last, First.

There are many options available when configuring the Outlook client. Review the options and descriptions for each before applying settings and changes to the Outlook Group Policy Objects.

Managing the Look and Feel of the Outlook Client

Another powerful function of using group policies is the ability for an administrator to define the look and feel of the Outlook client. Administrators can now configure options to create a specific look and feel when using Outlook.

Group Policy preferences can be defined to customize the look of the Outlook client. Options can be set to allow users access to information Web sites and SharePoint Portal Server sites, providing an enhanced user's experience and data access option not previously available.

Web Options Overview

Using the Preferences options of the GPO, settings can be defined to integrate and redirect Outlook users to valuable Web data using technologies such as Microsoft SharePoint Portal and Internet Information Services:

  • Custom Outlook Today Administrators can use the URL for Custom Outlook Today Properties settings to define a Web page that will be viewed when users access the Outlook Today home page.

  • Folder Home Pages Settings Each Outlook folder can now be redirected to a predefined Web page.

  • SharePoint Portal Server With Outlook 2003 and Group Policy preferences, support to integrate SharePoint with Outlook can easily be enabled and disabled.

Configuring and Applying Outlook Group Policy Settings

With all the information gathered in the previous sections, administrators can now apply settings and configuration options using the GPMC and Outlook 2003 security template. To better understand the settings for applying a group policy, review the following mock installation scenario.

In this scenario, you create and apply a standard set of preferences to create an Outlook client baseline configuration for one OU in the Active Directory domain. As described earlier, one additional setting is applied to redirect the client's Outlook Today setting and direct users to a company Internet home page.

To begin, open the GPMC by selecting Start, All Programs, Administrative Tools, Group Policy Management and then follow these steps:

1. | Select the Default Domain Policy by selecting Forest, Domains, YourCompanydomain, Group Policy Objects.
2. | Select the Default Domain Policy, click Action from the GPMC menu, and click Edit. This opens the Group Policy Editor.
3. | Select Administrative Templates under the User Configuration and select the Microsoft Outlook 2003 folder.

From this point, you can begin to enable options and apply preferences to the GPO. After options are enabled, they appear in the GPMC to be tested through RSoP and applied to the OU. In this scenario, you apply the HTML/Microsoft Word Email Editor options and redirect the Outlook Today page to point to a Web page called www.CompanyABC.com. To apply these settings, complete these steps:

1.
Select the Microsoft Outlook 2003 folder and select Tools, Options, Mail Format, Message Format.

2.
Double-click Message Format Editor in the right pane to open and configure the Message Format Policy settings.

3.
As shown in Figure 21.13, select Enabled Option and click HTML/Microsoft Word in the drop-down box. Select OK to continue.

Figure 21.13. Message Format Editor properties.

4.
Next, select the Outlook Today folder by selecting Microsoft Outlook 2003, Outlook Today.

5.
Double-click URL for Custom Outlook Today Properties in the right pane.

6.
To enable the redirection of the Outlook Today home page, click the Enable button and enter the URL to be displayed, as shown in Figure 21.14. Click OK when finished.

Figure 21.14. Custom Outlook Today properties.

7.
Open the GPMC and confirm that the settings are ready to be applied. From the GPMC, select Default Domain Policy and ensure that the Outlook settings appear as shown in Figure 21.15.

Figure 21.15. GPMC Outlook settings.

[View full size image]

Now that the Group Policy options have been configured, you apply the settings to a group of users in the domain by following these steps:

8.
To apply the settings to a group, click the Add button under Security Filtering in the right pane of the Default Domain Policy.

9.
From the Select Users, Computers, or Groups search page, enter the name of the group to which the settings will be applied and click OK.

10.
Check to see whether the group has been added to the Security Filtering pane.

When the configuration is completed, it is good practice to back up the configuration and ensure that all the settings are enabled on the GPO by selecting Action/GPO Status.

Customizing Administrative Group Policy Templates

Beyond using the custom and default templates, it is possible for you to create your own customized Administrative template to enforce a Registry change. The changes appear in the Group Policy GUI format and can be configured through the GPMC or ADUC the way normal Group Policy would be configured. Customized templates can be very useful in a highly customized environment or one where the default choices are not sufficient.

To best determine how to write a custom template, you must first consider what you are trying to control or change. You must also discover whether the Registry change is in the User or Computer hive area and then also note the actual Registry path and Registry value. After you have determined these items, coding a new basic administrative template is not too complex.

Administrative templates vary from the very basic to the extremely complex (look at the common.adm that is installed with Windows 2003). However, they can be extremely useful tools with which to customize any environment using Group Policy.


Working with Group Policy Objects

This section provides you with a simple list of "how to" items to get you started using Group Policy. If you are already comfortable working with Windows 2000 Group Policy Objects, this section will be review.

There are a variety of ways to open the Group Policy snap-in, from which you can edit, create, and delete Group Policy Objects.

Opening the Group Policy Snap-in

You can open the Group Policy Object Editor in several ways, depending on the action that you want to perform and the object to which you want to apply Group Policy. The preferred method is to use the Group Policy snap-in as an extension to an Active Directory snap-in. This way, you can browse the Active Directory for the correct Active Directory container and then define Group Policy Objects based on the selected scope.

To open the Group Policy Object Editor from Active Directory Users and Computers, perform the following steps:

1. | Open Active Directory Users and Computers.
2. | In the console tree, right-click the domain or organizational unit for which you want to set Group Policy Objects.
3. | Click Properties and then click the Group Policy tab.
4. | Edit or create a new Group Policy Object for the domain or OU you selected.

To open the Group Policy Object Editor as a Microsoft Management Console (MMC) snap-in, follow these steps:

1. | Open the Microsoft Management Console by typing mmc on the Run line.
2. | From the File menu, select Add/Remove Snap-in.
3. | On the Standalone tab, click Add.
4. | In the Available Standalone Snap-ins list, click Group Policy Object Editor and then click Add.
5. | In the Select Group Policy Object properties page, click Local Computer to edit the local Group Policy Object, or click Browse to find the Group Policy Object that you want to edit.
6. | Click Finish, click Close, and then click OK. The Group Policy Object Editor opens the Group Policy Object for you to edit.

Note

If you want to save a Group Policy Object Editor console and choose which Group Policy Object opens in it from the command line, select the Allow Focus of the Group Policy Snap-In To Be Changed When Launching from the Command Line check box in the Select Group Policy Object properties page.

Editing a Group Policy Object

After you open the Group Policy Object Editor, as shown in Figure 21.16, you can edit existing Group Policy Objects. It is important to note that you must have read and write permissions on a GPO to be able to edit it.

Figure 21.16. The Group Policy Object Editor.

[View full size image]

To edit a Group Policy Object, follow these steps:

1. | Open the Group Policy Object that you want to edit.
2. | In the console tree, double-click the folders to view the policies in the Details pane.
3. | In the Details pane, double-click a policy to open the properties page and then change the policy settings.

Note

If you want to edit the Local Group Policy Object, you can open it quickly by choosing Start, clicking Run, typing gpedit.msc, and then clicking OK.

Creating a Group Policy Object

If you want to create a new Group Policy Object, follow these steps:

1. | Open the Group Policy Object Editor from one of the ways documented in the previous sections.
2. | In the console tree, right-click the site, domain, or organizational unit to which you want the newly created Group Policy Object to be linked. The Group Policy Object will be stored in the current domainthat is, the domain that contains the domain controller being used by Active Directory Users and Computers or Active Directory Sites and Services.
3. | Click Properties and then click the Group Policy tab.
4. | Click New, type a name for the Group Policy Object, and then click Close.

Note

Use common sense naming conventions for GPOs. It is not advisable, for example, to use the same name for two different GPOs. Using the same name for different GPOs does not cause Group Policy to function incorrectly, but it might be confusing.

Deleting a Group Policy Object

The newly created Group Policy Object is linked by default to the site, domain, or organizational unit that you select when you create the Group Policy Object, and its settings apply to that site, domain, or organizational unit. If you want to delete the Group Policy Object from that site, domain, or organizational unit, do the following:

1. | Open Active Directory Users and Computers or Active Directory Sites and Services.
2. | In the console tree, right-click the site or domain, or right-click any organizational unit in the domain.
3. | Click Properties and then click the Group Policy tab.
4. | To find all the Group Policy Objects that are stored in the domain, click Add to open the Add a Group Policy Object Link properties page.
5. | Click the All tab, right-click the Group Policy Object that you want to delete, and then click Delete.
6. | Click Yes, click Cancel, and then click Close.

Unlinking a Group Policy Object

You might want to preserve a Group Policy Object that you have created but that you no longer want to affect the domain, OU, or site on which you created it. In this case, unlinking or disabling the GPO is your best practice.

To unlink a Group Policy Object from a domain, OU, or site, follow these steps:

1.
Open either Active Directory Users and Computers or Active Directory Sites and Services.

2.
In the console tree, right-click the site, domain, or organizational unit from which you want to unlink the Group Policy Object. Unlinking prevents the Group Policy Object from affecting that site, domain, or organizational unit.

3.
Click Properties and then click the Group Policy tab.

4.
Click the Group Policy Object that you want to unlink and then click Delete.

5.
In the Delete dialog box, click the Remove The Link From The List box, as shown in Figure 21.17. Next, click OK and then Close.

Figure 21.17. Unlinking a GPO.

Note

If you click the Remove The Link And Delete The Group Policy Object Permanently box in the Delete dialog box, all sites, domains, and organizational units to which the Group Policy Object is linked will no longer have those Group Policy settings applied to them, and the Group Policy Object itself will be deleted.

Disabling a Group Policy Object

When you disable a Group Policy Object link, the settings in the Group Policy Object no longer apply to users or computers in the site, domain, or organizational unit to which the Group Policy Object was linked; and they no longer apply to users and computers in child containers that inherit those Group Policy settings. However, you can easily reenable the policy at a later time.

To disable a Group Policy Object, perform the following steps:

1. | Open Active Directory Users and Computers or Active Directory Sites and Services.
2. | In the console tree, right-click the site, domain, or organizational unit to which the Group Policy Object is linked.
3. | Click Properties and then click the Group Policy tab.
4. | Right-click the Group Policy Object link that you want to disable, click Disabled on the context menu, and then click Yes. This switches the Disabled state to Active, and a check appears in the Disabled column.

Note

When you are working with Group Policy Objects, it is recommended that you disable unused parts of the object. Under User Configuration or Computer Configuration in the console tree, if a GPO contains only settings that are not configured, you can avoid processing these settings by disabling User Configuration or Computer Configuration. This expedites the startup and logon process for those users and computers that are subject to the policy.


Working Within the Group Policy Snap-in Namespace

The nodes of the Group Policy MMC snap-in are themselves MMC snap-in extensions. These extensions include Administrative Templates, Scripts, Security Settings, Software Installation, Folder Redirection, Remote Installation Services, and Internet Explorer maintenance. Extension snap-ins may, in turn, be extended. For example, the Security Settings snap-in includes several extension snap-ins. You can also create your own MMC extensions to the Group Policy snap-in to provide additional policies. The root node of the Group Policy snap-in is displayed as the name of the GPO and the domain to which it belongs.

Using Computer and User Configurations

Below the root node, the namespace is divided into two parent nodes: Computer Configuration and User Configuration. They are the parent folders that you use to configure Group Policy settings. Computer-related Group Policy is applied when the operating system boots. User-related Group Policy is applied when users log on to the computer.

Working with Software Settings

Three nodes exist under the Computer Configuration and User Configuration parent nodes: Software Settings, Windows Settings, and Administrative Templates. The Software Settings and Windows Settings nodes contain extension snap-ins that extend either or both of the Computer Configuration or User Configuration nodes.

Computer Configuration\Software Settings is for software settings that apply to all users who log on to the computer. This folder contains the Software Installation node, and it might contain other nodes that are placed there by independent software vendors.

User Configuration\Software Settings is for software settings that apply to users regardless of which computer they log on to. This folder also contains the Software Installation node. Deploying software will be discussed later in this section.

Working with Windows Settings

Windows Settings are available under both User Configuration and Computer Configuration in the console tree. Computer Configuration\Windows Settings is for Windows settings that apply to all users who log on to the computer. It includes two nodes: Security Settings and Scripts. User Configuration\Windows Settings is for Windows settings that apply to users regardless of which computer they log on to. It includes three core nodes: Folder Redirection, Security Settings, and Scripts.

Note

Depending on the various services you have installed, you might see other nodes such as Remote Installation Services, Internet Explorer Maintenance, or the like in this window.

Working with Security Settings

The Security Settings node allows a security administrator to configure security levels assigned to a Group Policy Object or local computer policy. This can be done after or instead of importing or applying a security template.

The Security Settings extension of the Group Policy snap-in, shown in Figure 21.18, complements existing system security tools such as the Security tab on the properties page (of an object, file, folder, and so on), and Local Users and Groups in Computer Management. You can continue to use existing tools to change specific settings, whenever necessary.

Figure 21.18. Security Settings in the GPO namespace.

[View full size image]

The security areas that can be configured for computers include the following:

  • Account Policies These computer security settings control password policy, lockout policy, and Kerberos policy in Windows Server 2003 and Windows 2000 domains.

  • Local Policies These security settings control audit policy, user rights assignment, and security options. Local policies allow you to configure who has local or network access to the computer and whether or how local events are audited.

  • Event Log This controls security settings for the Application, Security, and System event logs. You can access these logs using the Event Viewer.

  • Restricted Groups These settings allow you to control who should and should not belong to a restricted group, as well as which groups a restricted group should belong to. This capability allows you to enforce security policies regarding sensitive groups, such as Enterprise Administrators or Payroll. For example, an organization might decide that only Joe and Mary should be members of the Enterprise Administrators group. Restricted groups can be used to enforce that policy. If a third user is added to the group (for example, to accomplish some task in an emergency situation), the next time policy is enforced, that third user will be automatically removed from the Enterprise Administrators group.

  • System Services These settings control startup mode and security options (security descriptors) for system services such as network services, file and print services, telephone and fax services, Internet and intranet services, and so on.

  • Registry This is used to configure security settings for Registry keys, including access control, audit, and ownership. When you apply security policies on Registry keys, the Security Settings extension follows the same inheritance model as that used for all tree-structured hierarchies in Windows Server 2003 and 2000 (such as the Active Directory and NTFS). You should use the inheritance capabilities to specify security only at top-level objects, and redefine security only for those child objects that require it. This approach greatly simplifies your security structure and reduces the administrative overhead that results from a needlessly complex access-control structure.

  • File System This is used to configure security settings for filesystem objects, including access control, audit, and ownership.

  • Wireless Network Policies These policies help you to configure settings for a wide range of devices that access the network over wireless technologies.

  • Public Key Policies You use these settings to specify that computers automatically submit a certificate request to an enterprise certification authority and install the issued certificate. You also use public key policies to create and distribute a certificate trust list. public key policies can establish common trusted root certification authorities. You can also add encrypted data recovery agents and change the encrypted data recovery policy settings.

  • Software Restriction Policies These policies enable an administrator to set policies that restrict access and/or execution of application software.

  • IP Security Policies on Active Directory IP Security (IPSec) policy can be applied to the GPO of an Active Directory object. This propagates that IPSec policy to any computer accounts affected by that Group Policy Object.

Leveraging Administrative Templates

In Windows Server 2003, the Administrative Templates node of the Group Policy snap-in uses Administrative Template (.adm) files to specify the Registry settings that can be modified through the Group Policy snap-in user interface.

The Administrative Templates node includes all Registry-based Group Policy information. This includes Group Policy for the Windows 2000 and Windows Server 2003 operating systems, its components, and for applications. Policy settings pertaining to a user who logs on to a given workstation or server are written to the User portion of the Registry database under HKEY_CURRENT_USER (HKCU). Computer-specific settings are written to the Local Machine portion of the Registry under HKEY_LOCAL_MACHINE (HKLM).

A new Administrative Templates Web view in Windows Server 2003 uses the supported keyword to show you which operating systems are supported clients for individual settings. The Extended tab feature is new. It displays the text that explains the policy setting, as Windows 2000 did, and also indicates which versions of Windows are supported as clients for the setting. This enhancement is very helpful considering Windows Server 2003 adds more than 220 new administrative templates to the Group Policy arsenal. If you prefer a view of the policy setting without the explanatory text, click the Standard tab.

To use the view provided by administrative templates, follow these steps:

1.
Open the Group Policy Object Editor.

2.
In the console tree, click the folder under Administrative Templates that contains the policy settings you want to set.

3.
At the bottom of the Details pane, click the Extended tab. You'll see a screen similar to the one in Figure 21.19.

Figure 21.19. The Extended view of Administrative Templates.

[View full size image]

4.
In the Settings column, click the name or icon for a setting to read a description of the setting.

5.
To change that setting from its default (not configured) state, double-click the name or icon for the setting.

6.
On the Settings tab, click one of these buttons:

Not Configured The Registry is not modified.

Enabled The Registry reflects that the policy setting is selected.

Disabled The Registry reflects that the policy setting is not selected.

7.
Select any other available options that you want on the Settings tab and then click OK.

8.
To view and set other settings in the current folder, click Previous Setting or Next Setting.

Deploying Software Installations

The Software Installation snap-in can be used to centrally manage software distribution in your organization. You can assign and publish software for groups of users and computers.

When applications are assigned to groups of users, all users who require the applications automatically have the application on their desktopswithout requiring the administrator or technical personnel to set up the application on each desktop. When an application is assigned to a group of users, the application is actually advertised on all the users' desktops. The next time a user logs on to her workstation, the application is advertised. This means that the application shortcut appears on the Start menu, and the Registry is updated with information about the application, including the location of the application package and the location of the source files for the installation. With this advertisement information on the user's computer, the application is installed the first time the user activates the application. When the user selects the application from the Start menu the first time, it sets up automatically and then opens.

Applications can also be published to groups of users, making the application available for users to install, should they choose to do so. When an application is published, no shortcuts to the application appear on users' desktops, and no local Registry entries are made. That is, the application has no presence on users' desktops. Published applications store their advertisement information in the Active Directory.

To install a published application, users can use the Add/Remove Programs applet in the Control Panel, which includes a list of all published applications that are available for them to use. Alternatively, if the administrator has configured this feature, users can open a document file associated with a published application (for example, an .xls file to install Microsoft Excel).

Creating and Modifying Scripts

With the scripts extensions, you can assign scripts to run when the computer starts or shuts down or when users log on or off their computers. For this purpose, you can use Windows Scripting Host to include both Visual Basic Scripting Edition (VBScript) and JScript development software script types.

Group Policy Object Editor includes two extensions for script deployment:

  • Scripts (Startup/Shutdown) You can use this extension, located under the Computer Configuration\Windows Settings in the console tree, to specify scripts that are to run when the computer starts up or shuts down. These scripts run as Local System, which means they have the full rights that are associated with the System account.

  • Scripts (Logon/Logoff) You can use this extension, located in the User Configuration\Windows Settings in the console tree, to specify scripts when the user logs on or off the computer. These scripts run as User, not as Administrator.

This means that the user must have rights to perform the functions of your logon/logoff script.

Whether it's a startup/shutdown or a logon/logoff script, the procedure for assigning the script to a computer is the same. To assign computer startup scripts, perform the following steps:

1. | Open the Group Policy Object Editor.
2. | In the console tree, click Scripts (Startup/Shutdown).
3. | In the Details pane, double-click Startup.
4. | In the Startup properties page, click Add.
5. | On the Add a Script properties page, do the following:

In the Script Name box, type the path and name to the script, as shown in Figure 21.20, or click Browse to search for the script file in the Netlogon share of the domain controller.

Figure 21.20. Adding a logon.bat file as a startup script.

In the Script Parameters box, type any parameters you want, the same way as you would type them on the command line.

Note

You must be logged on as a member of the Domain Administrators, Enterprise Administrators, or Group Policy Creator Owners security group to assign scripts.


Summary

Windows Server 2003 builds on the functionality of group policy management technologies developed in Windows 2000. Window Server 2003 introduces powerful new change and configuration management features that provide greater flexibility and precision for managing users and computers in increasingly complex enterprise environments. While it is common that organizations deploying Active Directory do not immediately leverage the full capabilities of group policies in their environment, they can provide significant savings in effort, administration, and management time and should be leveraged as much as possible in an organization.


Best Practices

  • Use common sense naming conventions for GPOs. Don't use the same name for two different GPOs.

  • When you are working with Group Policy Objects, disable unused parts of the object.

  • When you delegate creation of GPOs to non-administrators, also consider delegating the capability to manage the links for a specific OU.

  • Use the No Override and Block settings in GPOs sparingly.

  • Do not redirect My Documents to the home directory unless you have already deployed home directories in your organization.

  • Enable client-side caching, especially for users with portable computers.

  • Always enable the Synchronize All Offline Files Before Logging Group Policy setting to ensure that offline files are fully synchronized and available to users working offline.

  • Use fully qualified (UNC) pathsfor example, \\server\share.

  • Avoid applying group policies to sites; instead, apply them to domains and organizational units.

  • Use RSoP to help you determine a set of applied policies and their precedence.

  • Software packages must be in the format of an .msi package; otherwise, the package cannot be pushed using Group Policy.

  • Configure software pushes at the highest levels possible so that the push goes out to a broader group of OUs. However, if the push is going out to only a few OUs, the software should be pushed from the OU level.

  • Configure software pushes to the Computer Configuration rather than the User Configuration.

  • Use DFS for multiple-site software installation MSI locations. Using DFS ensures that software installations are installed at the closest source for installation.

  • Force after-hours automatic reboots if possible. Use a remote shutdown command (such as the DOS shutdown command or VBScript) to force computers that are to receive a software push to install software after the users have left for the day.

  • Know the implications of using the Authenticated Users group to push software. Despite its name, Authenticated Users actually includes both users and computers.


Chapter 22. Windows Server 2003 Management and Maintenance Practices

In This Chapter

  • Managing Windows Server 2003

  • Auditing the Environment

  • Managing Windows Server 2003 Remotely

  • Identifying Security Risks

  • Tracking and Managing Licenses

  • Using Microsoft Operations Manager to Simplify Management

  • Employing Windows Server 2003 Maintenance Practices

  • Keeping Up with Service Packs and Updates

  • Maintaining Windows Server 2003

  • Summary of Maintenance Tasks and Recommendations

Windows Server 2003 systems are the heart of the IT infrastructure that supports businesses. These servers need to be managed and maintained to keep the businesses running optimally. Server management and maintenance help maximize investment in infrastructure and productivity. They also keep the IT infrastructure running effectively and efficiently to boost availability and reliability.

Server management entails many different tasks; they include, but are not limited to, administering and supervising servers based on functional roles, proactively monitoring the network environment, keeping track of activity, and implementing solid change control practices. These management functions for Windows Server 2003 can be performed both locally and remotely.

As systems' workloads, capacities, and usage change in the environment, the systems need to be maintained so that they operate as efficiently as possible. Without such maintenance, systems become more susceptible to causing slower response times and decreased reliability. Efforts to maintain those systems should be made periodically to avoid any inefficiency. This chapter covers best practices on ways an organization can maintain and manage its Windows Server 2003 environment.


Managing Windows Server 2003

Many aspects of an IT infrastructure need to be managed. They can include managing servers based on their functional roles in the network environment, auditing network activity and usage, and monitoring the environment.

Microsoft has come a long way with how servers can be managed. Windows Server 2003 management can be handled locally or remotely. Although local and remote management was possible in previous Windows versions, Windows Server 2003 supersedes that functionality with new and improved processes and tools that assist administrators in their management.

Managing Based on Server Roles

Windows Server 2003 systems can participate in various responsibilities in a given network environment. Some of these responsibilities may be intertwined due to budget constraints, business requirements, or technical justifications. No matter how the roles and responsibilities play out in the environment, it's important to manage them appropriately based on the roles of the server. The management aspects for some of the roles that Windows Server 2003 can undertake are examined in the following sections.

File Servers

File servers are primarily responsible for keeping data. This data must be available and quickly accessed. As such, management of these servers can entail using the Disk Defragmenter utility, shown in Figure 22.1, to keep file access optimized. This helps keep reading and writing to disk more efficient than if files and the disk were fragmented.

Figure 22.1. The Disk Defragmenter utility.

[View full size image]

Disk capacity must also be managed so that there is always ample space available for additional data. Quota management can also be an integral part of file server management. Disk quotas are used to control the amount of disk space that is available to the end users. When a disk quota is set, a specified amount of space on a volume can be set aside for a user. Warning messages can be sent to the user as the quota approaches the limit. This is illustrated in Figure 22.2. If an attempt to save data exceeds the limit, the user can be prevented from saving the file.

Figure 22.2. Assigning disk quotas.

Print Servers

Managing print servers is an important but often overlooked aspect of managing Windows Server 2003. This is true mostly because printers on Windows Server 2003 are simple to manage. Although there is less management required for a print server, printing should still be audited and monitored.

Auditing and monitoring printing ensures that users can print successfully and that the server and printers are fully operational. Print jobs on the server can be managed and viewed through either the printer queue or properties window. If the print server also has Internet printing enabled, print job information can be viewed using the print server's Web pages. The type of information that can be viewed and managed includes

  • Print job name

  • Print job status

  • Print job owner

  • Number of pages to print

  • Print job size

  • Submission time

In addition to the preceding information, the System Monitor can be used to provide a plethora of information about print usage on the system, such as

  • Bytes printed/sec

  • Job errors

  • Jobs

  • Job spooling

  • Maximum jobs spooling

  • Maximum references

  • Not-ready errors

  • Out-of-paper errors

  • References

  • Total jobs printed

  • Total pages printed

The information obtained from the print server listing can assist an administrator in proactively managing the printers and print devices. For instance, if it is determined that large print jobs performed at certain times of the day affect other print jobs, a print queue for large print jobs can be created to offload those jobs to after-hours printing only.

Web Servers

Windows Server 2003 Web servers offer an assortment of Internet-related functionalities, such as HTTP, FTP, SMTP, and more. Each of the services employed on the server must be managed to keep content and services up to date. The following are some areas to consider managing:

  • IIS metabase The IIS metabase holds IIS-related configuration information. As changes occur to an IIS system, you can verify that the IIS metabase has been backed up (see Figure 22.3). You can do so by selecting Action, All Tasks, Backup/Restore Configuration within the IIS Manager.

  • Web applications and content The installed Web-based applications most likely require additional management that is separate from IIS. The content that is to be displayed such as ASP, static, and dynamic content should be periodically managed as well.

  • IIS logging IIS logging allows administrators to monitor activity on the Web server. It also allows the administrator to manage the Web server's security.

Figure 22.3. Verifying IIS metabase backups.

Messaging Servers

Messaging servers require special attention so that services run efficiently and effectively. In particular, Exchange servers require attention to the messaging databases, auditing, security, and user management. Exchange systems can be monitored using the System Monitor. Specific Exchange-related objects are installed so that administrators can easily pinpoint Exchange performance indicators.

Exchange services are managed by the Exchange management snap-in as well as the Active Directory Users and Computers MMC snap-in. For instance, user accounts are mail-enabled in the Active Directory Users and Computers snap-in, while other configurations are managed through the Exchange management snap-in.

Terminal Servers

Windows Server 2003 Terminal Servers provide a thin-client approach to computing in which all the processing is done at the server. Only screen images, keystrokes, and mouse movements are sent to the client. Managing Terminal Servers can involve many aspects, including the following:

  • Applications Applications must be installed through the Add or Remove Programs applet so that multiple users can run them. These applications should also be monitored to ensure that they are adequately servicing the end users.

  • User sessions User sessions, including remote control of those sessions, should be managed to properly accommodate the users. For example, enabling the use of roaming profiles gives the users their desktop settings even though they're logging on to another system. Equally important is monitoring those user sessions. This will give administrators information on the resource requirements per user. This information can be used to more appropriately size the system to accommodate various usage scenarios.

Domain Controllers

Domain controllers (DCs) host Active Directory (AD), which contains most, if not all, objects in the Windows Server 2003 environment. AD has many functional roles in a Windows Server 2003 environment, including object management (additions, modifications, or deletions), authentication, replication, security, and more.

Managing these AD roles can be intimidating, especially in larger environments, but AD has many useful utilities to help manage the directory. They include, but are not limited to, Active Directory Domains and Trusts, Active Directory Sites and Services, and Active Directory Users and Computers. Some of the areas that these tools can manage include

  • Users

  • Groups

  • Domains

  • Sites

  • Organizational units (OUs)

  • Computers

There are many other tools to manage that are included in Windows Server 2003 as command-line tools, Windows Server 2003 Support Tools, and the Windows Server 2003 Resource Kit. Also, countless third-party management utilities are developed specifically for AD.


Auditing the Environment

Auditing is a way to gather and keep track of activity on the network, devices, and entire systems. By default, Windows Server 2003 enables some auditing, whereas many other auditing functions must be manually turned on. This allows for easy customization of the features the system should have monitored.

Auditing is typically used for identifying security breaches or suspicious activity. However, auditing is also important to gain insight into how the network, network devices, and systems are accessed. As it pertains to Windows Server 2003, auditing can be used to monitor successful and unsuccessful events on the system. Windows Server 2003's auditing policies must first be enabled before activity can be monitored.

Auditing Policies

Audit policies are the basis for auditing events on a Windows Server 2003 system. Depending on the policies set, auditing may require a substantial amount of server resources in addition to those resources supporting the server's functionality. Otherwise, it could potentially slow server performance. Also, collecting lots of information is only as good as the evaluation of the audit logs. In other words, if a lot of information is captured and a significant amount of effort is required to evaluate those audit logs, the whole purpose of auditing is not as effective. As a result, it's important to take the time to properly plan how the system will be audited. This allows the administrator to determine what needs to be audited, and why, without creating an abundance of overhead.

Audit policies can track successful or unsuccessful event activity in a Windows Server 2003 environment. These policies can audit the success and failure of events. The types of events that can be monitored include

  • Account logon events Each time a user attempts to log on, the successful or unsuccessful event can be recorded. Failed logon attempts can include logon failures for unknown user accounts, time restriction violations, expired user accounts, insufficient rights for the user to log on locally, expired account passwords, and locked-out accounts.

  • Account management When an account is changed, an event can be logged and later examined.

  • Directory service access Any time a user attempts to access an Active Directory object that has its own system access control list (SACL), the event is logged.

  • Logon events Logons over the network or by services are logged.

  • Object access The object access policy logs an event when a user attempts to access a resource (for example, a printer or shared folder).

  • Policy change Each time an attempt to change a policy (user rights, account audit policies, trust policies) is made, the event is recorded.

  • Privileged use Privileged use is a security setting and can include a user employing a user right, changing the system time, and more. Successful or unsuccessful attempts can be logged.

  • Process tracking An event can be logged for each program or process that a user launches while accessing a system. This information can be very detailed and take a significant amount of resources.

  • System events The system events policy logs specific system events such as a computer restart or shutdown.

The audit policies can be enabled or disabled through either the local system policy, domain controller security policy, or Group Policy Objects. Audit policies are located within the Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy folder, as shown in Figure 22.4.

Figure 22.4. Windows Server 2003 audit policies.

[View full size image]

Tracking Logon and Logoff Events

As mentioned earlier, both successful and unsuccessful account logon and logoff events can be audited. By default, Windows Server 2003 audits successful account logon and logoff events. When the audit policy is enabled, events are cataloged in the Event Viewer's Security log.

Monitoring Resource Access

After enabling the object access policy, the administrator can make auditing changes through the property pages of a file, folder, or the Registry. If the object access policy is enabled for both success and failure, the administrator will be able to audit both successes and failures for a file, folder, or the Registry.

Note

Monitoring both success and failure resource access can place additional strain on the system. It is therefore recommended to test this in a segmented lab environment prior to implementing this level of auditing in the production environment.

Monitoring Files and Folders

The network administrator can tailor the way Windows Server 2003 audits files and folders through the property pages for those files or folders. Keep in mind that the more files and folders that are audited, the more events that can be generated, which can increase administrative overhead. Therefore, choose wisely which files and folders to audit. To audit a file or folder, do the following:

1.
In Windows Explorer, right-click the file or folder to audit and select Properties.

2.
Select the Security tab and then click the Advanced button.

3.
In the Advanced Security Settings window, as shown in Figure 22.5, select the Auditing tab.

Figure 22.5. The Advanced Security Settings window.

[View full size image]

4.
Click the Add button to display the Select User or Group window.

5.
Enter the name of the user or group to audit when accessing the file or folder. Click the Check Names button to verify the name.

6.
Click OK to open the Auditing Entries window.

7.
In the Auditing Entries window, shown in Figure 22.6, select which events to audit for successes or failures.

Figure 22.6. The Auditing Entries window.

[View full size image]

8.
Click OK three times to exit.

When the file or folder is accessed, an event is written to the Event Viewer's Security log. The category for the event is Object Access. An Object Access event is shown in Figure 22.7.

Figure 22.7. An Object Access event in the Security log.

Monitoring Printers

Printer auditing operates on the same basic principles as file and folder auditing. In fact, the same step-by-step procedures for configuring file and folder auditing apply to printers. The difference lies in what successes and failures can be audited. These events include

  • Print

  • Manage printers

  • Manage documents

  • Read permissions

  • Change permissions

  • Take ownership

These events are stored in the Event Viewer's Security log.


Managing Windows Server 2003 Remotely

Windows Server 2003's built-in feature set allows it to be easily managed remotely. This capability eases administration time, expenses, and energy by allowing administrators to manage systems from remote locations rather than having to be physically at the system.

Many tools are available to remotely manage a system. They include, but aren't limited to, the following:

  • Microsoft Management Console (MMC) The MMC not only provides a unified interface for most, if not all, graphical interface utilities, but it also can be used to connect and manage remote systems. For example, administrators can use the Event Viewer to examine event logs on the local machine as well as a remote system.

  • Remote Desktop for Administration This tool empowers administrators to log on to a remote system as if they were logging on to the system locally. The desktop and all functions are at the administrators' disposal.

  • Scripting with Windows Scripting Host (WSH) Scripting on Windows Server 2003 can permit administrators to automate tasks locally or remotely. These scripts can be written using common scripting languages.

  • Command-line utilities Many command-line utilities are capable of managing systems remotely.

Administrative Tools

Many of the administrative tools that are familiar from previous versions of Windows are present in Windows Server 2003. Keeping much of the toolset the same reduces the learning curve associated with learning new utilities.

Windows Server 2003 also includes some new administrative tools and some familiar tools that were provided in earlier Support Tools and Resource Kit versions all built into the operating system. These tools, which help with system management, include the following:

  • PowerCfg.exe This tool enables administrators to configure the power settings such as ACPI/hibernate state settings.

  • WHOAMI.EXE WHOAMI is a classic logon script tool that returns a domain name, computer name, username, group names, logon identifier, and privileges for the user who is currently logged on.

  • WHERE.EXE This tool locates and displays all the files that match the given parameter. The WHERE tool displays the current directory if no parameters are given.

  • FORFILES.EXE FORFILES can be used to enhance batch file control by selecting a file or group of files and executing a command on the file.

  • FREEDISK.EXE This utility displays the amount of free space on a disk. This information can be very useful for checking space before launching scripts.

  • GETTYPE.EXE This tool determines the Windows SKU type and sets the system environment variable %ERRORLEVEL% to the value associated with the specified Windows operating system.

  • INUSE.EXE INUSE is used to replace files on the next reboot.

  • SETX.EXE This tool sets environment variables.

  • TIMEOUT.EXE This tool allows an idle or timeout period, and it can be used in scripts.

  • CHOICE.EXE CHOICE enhances batch file control by allowing a choice to be made from a menu item.

  • TAKEOWN.EXE This tool sets ownership ACL on files.

Note

Visual Basic script tools can now be digitally signed to foster safer administration and management. Organizations that want to enhance security by preventing just any VB script from being run on a system can digitally sign the script. When a script is executed, a policy can be set to validate that the script has been signed by the organization and is valid for use.

Remote Desktop for Administration

Remote Desktop for Administration, formerly known as Terminal Services Remote Administration mode, allows administrators to log on to a Windows Server 2003 system remotely as if they were logging on locally. This facilitates the remote administration of the entire server and reduces the amount of local administration required.

An administrator logging in to a server through Remote Administration mode can view a graphical interface just as she would if she were logging in at the local server. Therefore, administrators can use all the available tools and access all aspects of the server from a Terminal Services client session.

Note

The Remote Desktop snap-in can be used to connect to multiple Terminal Services servers or computers with the Remote Desktop for Administration enabled.

Remote Desktop for Administration is disabled by default, but it can be enabled by doing the following:

1.
Double-click the System applet located in the Control Panel.

2.
Select the Remote tab, as illustrated in Figure 22.8.

Figure 22.8. The Remote tab used to configure Remote Desktop for Administration.

3.
Select Allow Users to Connect Remotely to This Computer under the Remote Desktop area.

4.
Administrators can now connect remotely to the server. You can optionally add other users by clicking the Select Remote Users button to display the Remote Desktop Users window.

5.
Click Add to display the Select Users window.

6.
Add the appropriate users to log on to the server.

Note

It is highly recommended that only administrators allowed to access the server.

7.
Click OK three times to exit.

Using the Remote Control Add-on for Active Directory Users and Computers

A significant add-on to Windows 2003 for network administrators is the Remote Control Add-on for Active Directory Users and Computers. This tool provides an administrator with the ability to right-click on a computer account in the Active Directory MMC and choose to remotely administer the system. The tool effectively launches a Terminal Services/Remote Desktop connection to the system.

The Remote Control Add-on for Active Directory Users and Computers is freely downloadable to all network administrators that have legal licenses to Windows 2003. The add-on is available at http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx.

Using Telnet for Remote Access Management

Another remote access management mechanism is Telnet. Telnet is a gateway type of service through which an administrator or client can connect and log on to a server running the Telnet Server service. Although this is a viable service for administering the system, other remote management mechanisms such as Remote Desktop for Administration allow for greater flexibility and control.

Caution

Telnet sends usernames and passwords across the network in plain text.

WinRM for Remote Management

Windows Remote Management (WinRM) is new to Windows 2003 R2. It is the Microsoft implementation of WS-Management. WS-Management is a protocol that allows for hardware and software from diverse vendors to communicate. What differentiates WinRM from previous implementations is that it is SOAP-based and doesn't use DCOM for remote connections. This makes this implementation of the WS-Management protocol very firewall friendly and scalable in a mixed operating system environment. Data is stored in an extensible XML format, not in objects, so it can be accessed by many common system and network management platforms. It can also be accessed by the new WinRM API, WMI scripting, or through a COM application. WinRM is available via the command line as well as through the Winrm.cmd tool. This can be integrated to batch files or integrated into Visual Basic scripts and applications through Winrm.vbs. More information on the command-line tool and its syntax can be found at the dedicated WinRM web page on Microsoft TechNet.

Note

WinRM requires Windows Server 2003 R2 and is not installed by default. You may explicitly add this feature through the Add/Remove Windows Components tool in the Control Panel.


Identifying Security Risks

A network's security is only as good as the security mechanisms put into placeand the review and identification process. Strong security entails employing Windows Server 2003 security measures such as authentication, auditing, and authorization controls, but it also means that security information is properly and promptly reviewed. Information that can be reviewed includes, but isn't limited to, Event Viewer logs, service-specific logs, application logs, and performance data.

All the security information for Windows Server 2003 can be logged, but without a formal review and identification process, the information is useless. Also, security-related information can be complex and unwieldy depending on what information is being recorded. For this reason, manually reviewing the security information may be tedious but can prevent system or network compromise.

The formal review and identification process should be performed daily. Any identified activity that is suspicious or could be potentially risky should be reported and dealt with appropriately. For instance, an administrator reviewing a particular security log may run across some data that may alert him of suspicious activity. This incident would then be reported to the security administrator to take the appropriate action. Whatever the course of action may be in the organization, there should be points of escalation and remediation.


Tracking and Managing Licenses

Licensing is typically one of the management areas that administrators would like to opt out of managing. It is often perceived as a tedious and time-consuming task. Windows Server 2003 provides two tools designed to help minimize the burdens of license tracking and management: the Licensing applet in the Control Panel and the Licensing snap-in located in the Start, Programs, Administrative Tools menu.

The Licensing applet in the Control Panel manages Microsoft BackOffice products on the local system. As one might expect, an administrator can add, remove, or change licensing options. However, the administrator can also configure the interval for licensing information to be replicated to the site license server.

The Licensing snap-in in the Administrative Tools menu is the site license server managing licensing for the enterprise. In addition to adding, deleting, or changing licensing, many useful tasks can be accomplished with licensing using this tool, including

  • Managing licensing for other servers in the environment

  • Reviewing licensing usage

  • Managing licensing replication throughout the network


Using Microsoft Operations Manager to Simplify Management

Microsoft Operations Manager (MOM) is an enterprise-class monitoring and management solution for Windows environments. It is designed to simplify Windows management by consolidating events, performance data, alerts, and more into a centralized repository. Reports on this information can then be tailored depending on the environment and on the level of detail that is needed and extrapolated. This information can assist administrators and decision makers in proactively addressing Windows Server 2003 operation and any problems that exist or may occur. For more information on using MOM, refer to Chapter 25, "Integrating Microsoft Operations Manager with Windows Server 2003."

Many other intrinsic benefits are gained by using MOM, including but not limited to

  • Event log monitoring and consolidation

  • Monitoring of various applications, including those provided by third parties

  • Enhanced alerting capabilities

  • Assistance with capacity-planning efforts

  • A customizable knowledge base of Microsoft product knowledge and best practices

  • Web-based interface for reporting and monitoring


Employing Windows Server 2003 Maintenance Practices

Administrators face the often-daunting task of maintaining the Windows Server 2003 environment in the midst of daily administration and firefighting. Little time is spent identifying and then organizing maintenance processes and procedures.

To decrease the number of administrative inefficiencies and the amount of firefighting an administrator must go through, it's important to identify those tasks that are important to the system's overall health and security. After they've been identified, routines should be set to ensure that the Windows Server 2003 environment is stable and reliable. Many of the maintenance processes and procedures described in the following sections are the most opportune areas to maintain.

Maintaining DHCP and WINS

DHCP and WINS are low-maintenance services in Windows Server 2003, but as with any other database, it's important to regularly check these databases to keep them running as efficiently as possible.

WINS provides NetBIOS name resolution and uses the Extensible Storage Engine (ESE) to store system entries. The WINS database continuously updates itself by adding or deleting entries. Over time, the WINS database can contain a lot of unused space due to the changes. As a result, the database should be compacted to regain the unused space and service the environment faster and more efficiently. Windows Server 2003 dynamically compacts the database, but offline compaction is required periodically as well. Before proceeding with compaction, make sure that WINS has been successfully backed up.

With the exception of the first backup, WINS backups happen automatically in Windows Server 2003. To back up the WINS database, follow these steps:

1. | Select Mappings, Back Up Database within the WINS Manager.
2. | Specify a location for the backup files and click OK. WINS will then automatically back up its database every 24 hours.

If the WINS database ever becomes corrupted, simply stop and restart the WINS service. If WINS detects corruption, it will automatically restore the most recent backup. If WINS does not detect the corruption, the administrator can force a restore by selecting Mappings, Restore Database from the WINS Manager.

WINS is also designed to compact its databases automatically when they become too large. However, the administrator should compact them manually periodically. For large Windows Server 2003 environments with 1,000 systems, Microsoft recommends manually compacting the database once a month. To manually compact the WINS database, follow these steps:

1. | Within a command-prompt window, change the directory path to show %systemroot%\systems32\wins and then type Net Stop WINS.
2. | Type the command JETPACK WINS.MDB TEMP.MDB.
3. | Type the command NET START WINS.

DHCP maintenance is less complex than WINS maintenance. The DHCP database and related Registry entries, as listed here, are automatically backed up every 15 minutes by default. Also, the DHCP database is automatically compacted at specific intervals.

  • DHCP.mdb The DHCP server database file.

  • DHCP.tmp This temporary file is used by the database as a swap file during database indexing maintenance operations.

  • J50.log and J50#####.log These database transaction log files can be used to recover DHCP if necessary.

  • J50.chk A checkpoint file.

Note

Specific backup and maintenance instructions are covered in detail in Chapter 10, "DHCP/WINS/Domain Controllers."

Maintaining DNS Aging and Scavenging

Similar to WINS and DHCP, DNS operates efficiently on its own and requires very little intervention or maintenance. However, one way to maintain DNS is to set aging and scavenging.

Depending on the number of updates and the number of records, DNS can potentially experience problems with removing stale records. Although this doesn't necessarily cause performance degradation or resolution problems in smaller networks, it may affect larger ones. As such, it's important to periodically scavenge the DNS database. Aging and scavenging are not enabled by default, so they must manually be enabled by selecting Action, Set Aging/Scavenging within the DNS snap-in. (Make sure the appropriate server is highlighted first.) Then check the box within the Server Aging/Scavenging Properties window and set the appropriate intervals, as shown in Figure 22.9.

Figure 22.9. Enabling aging/scavenging for DNS.

Previous Page
Next Page


Keeping Up with Service Packs and Updates

Service packs (SPs) and updates for both the operating system and applications are vital parts to maintaining availability, reliability, performance, and security. Microsoft packages these updates into SPs or individually.

There are several ways an administrator can update a system with the latest SP or update: CD-ROM, manually entered commands (see Table 22.1 and Table 22.2), Windows Update, or Microsoft Software Update Server (SUS).

Table 22.1. SP Command-Line Parameters

Service Pack (Update.exe) Parameters

Description

-f

Forces applications to close at shutdown.

-n

Prevents the system files from being backed up. This keeps SPs from being uninstalled.

-o

Overwrites OEM files.

-q

Indicates Quiet mode; no user interaction is required.

-s

Integrates the SP in a Windows Server 2003 share.

-u

Installs SP in unattended mode.

-z

Keeps the system from rebooting after installation.

Table 22.2. Update Command-Line Parameters

Hotfix.exe Parameters

Description

-f

Forces applications to close at shutdown.

-l

Lists installed updates.

-m

Indicates Unattended mode.

-n

Prevents the system files from being backed up. This keeps updates from being uninstalled.

-q

Indicates Quiet mode; no interaction is required.

-y

Uninstalls the update.

-z

Keeps the system from rebooting after installation.

Note

Thoroughly test and evaluate SPs and updates in a lab environment before installing them on production servers and client machines. Also, install the appropriate SPs and updates on each production server and client machine to keep all systems consistent.

Windows Update

Windows Update, shown in Figure 22.10, is a Web site that scans a local system and determines whether there are updates to apply to that system. Windows Update is a great way to update individual systems, but this method is sufficient for only a small number of systems. If administrators choose this method to update an entire organization, there would be an unnecessary amount of administration.

Figure 22.10. The Windows Update Web site.

[View full size image]

Software Update Services

Realizing the increased administration and management efforts administrators must face when using Windows Update to keep up with SPs and updates for anything other than small environments, Microsoft has created the Software Update Services (SUS) client and server versions to minimize administration, management, and maintenance of mid- to large-sized organizations. Figure 22.11 illustrates the SUS interface. SUS communicates directly and securely with Microsoft to gather the latest SPs and updates.

Figure 22.11. Software Update Services.

[View full size image]

The SPs and updates downloaded onto SUS can then be distributed to either a lab server for testing (recommended) or to a production server for distribution. After these updates are tested, SUS can automatically update systems inside the network.

Note

You can find more information on SUS and download the product from http://www.microsoft.com/windows2000/windowsupdate/sus/.

Maintaining Consistency

Maintaining a consistent level of patches and security fixes across an organization is a challenge. These challenges can be minimized if you're using SUS. If you're not using SUS, Microsoft provides other utilities to make maintenance and management of SPs and updates easier. They include but aren't limited to the following:

  • QChain This utility safely chains updates together to allow multiple updates to be installed with only one reboot.

  • Microsoft Security Notification Service Subscribing to this service ensures that administrators will be notified as security-related updates become available.

  • Microsoft Baseline Security Advisor (MBSA) MBSA is both a graphical and command linedriven tool that improves upon the capabilities of the HFNetCHK tool. It scans for common system security misconfigurations (in products such as Windows, IIS, SQL Server, Internet Explorer [IE], and Office) and missing security updates for other products as well.


Maintaining Windows Server 2003

Maintaining Windows Server 2003 systems isn't an easy task for administrators. They must find time in their firefighting efforts to focus and plan for maintenance on the server systems. When maintenance tasks are commonplace in an environment, they can alleviate many of the common firefighting tasks.

The processes and procedures for maintaining Windows Server 2003 systems can be separated based on the appropriate time to maintain a particular aspect of Windows Server 2003. Some maintenance procedures require daily attention, whereas others may require only yearly checkups. The maintenance processes and procedures that an organization follows depend strictly on the organization; however, the categories described in the following sections and their corresponding procedures are best practices for organizations of all sizes and varying IT infrastructures.

Note

These tasks are in addition to those examined earlier in this chapter.

Daily Maintenance

Certain maintenance procedures require more attention than others. The procedures that require the most attention are categorized into the daily procedures. Therefore, it is recommended that an administrator take on these procedures each day to ensure system reliability, availability, performance, and security. These procedures are examined in the following three sections.

Checking Overall Server Functionality

Although checking the overall server health and functionality may seem redundant or elementary, this procedure is critical to keeping the system environment and users working productively.

Some questions that should be addressed during the checking and verification process are the following:

  • Can users access data on file servers?

  • Are printers printing properly? Are there long queues for certain printers?

  • Is there an exceptionally long wait to log on (that is, longer than normal)?

  • Can users access messaging systems?

  • Can users access external resources?

Verifying That Backups Are Successful

To provide a secure and fault-tolerant organization, it is imperative that a successful backup to tape be performed each night. In the event of a server failure, the administrator may be required to perform a restoration from tape. Without a backup each night, the IT organization will be forced to rely on rebuilding the server without the data. Therefore, the administrator should always back up servers so that the IT organization can restore them with minimum downtime in the event of a disaster. Because of the importance of the tape backups, the first priority of the administrator each day needs to be verifying and maintaining the backup sets.

If disaster ever strikes, the administrators want to be confident that a system or entire site can be recovered as quickly as possible. Successful backup mechanisms are imperative to the recovery operation; recoveries are only as good as the most recent backups.

Although Windows Server 2003's backup program does not offer alerting mechanisms for bringing attention to unsuccessful backups, many third-party programs do. In addition, many of these third-party backup programs can send emails or pages if backups are successful or unsuccessful.

Monitoring the Event Viewer

The Event Viewer, shown in Figure 22.12, is used to check the System, Security, Application, and other logs on a local or remote system. These logs are an invaluable source of information regarding the system. The following event logs are present for Windows Server 2003 systems:

Figure 22.12. The Event Viewer utility.

[View full size image]

  • Security log The Security log captures all security-related events that are being audited on a system. Auditing is turned on by default to record success and failure of security events.

  • Application log Specific application information is stored in the Application log. This information includes services and any applications that are running on the server.

  • System log Windows Server 2003specific information is stored in the System log.

Domain controllers also have these additional logs:

  • File Replication Service Any events relating to the File Replication Service are captured in this log.

  • Directory Service Events regarding Active Directory, such as connection problems with a global catalog server or replication problems, are recorded here.

  • DNS Server Anything having to do with the DNS service is cataloged in the DNS Server log.

All Event Viewer events are categorized either as informational, warning, or error. Logs show events of the types shown in Figure 22.13.

Figure 22.13. Event types.

Note

Checking these logs often will help your understanding of them. There are some events that constantly appear but aren't significant. Events will begin to look familiar, so you will notice when something is new or amiss in your event logs.

Some best practices for monitoring event logs include

  • Understanding the events that are being reported

  • Setting up a database for archived event logs

  • Archiving event logs frequently

To simplify monitoring hundreds or thousands of generated events each day, the administrator should use the filtering mechanism provided in the Event Viewer. Although warnings and errors should take priority, the informational events should be reviewed to track what was happening before the problem occurred. After the administrator reviews the informational events, she can filter out the informational events and view only the warnings and errors.

To filter events, do the following:

1. | Start the Event Viewer by choosing Start, Programs, Administrative Tools.
2. | Select the log from which you want to filter events.
3. | Right-click the log and select View, Filter.
4. | In the log properties window, as shown in Figure 22.13, select the types of events to filter.
5. | Optionally, select the time frame in which the events occurred. Click OK when you're done.

Some warnings and errors are normal because of bandwidth constraints or other environmental issues. The more you monitor the logs, the more familiar you will become with the messages and therefore will be able to spot a problem before it affects the user community.

Tip

You may need to increase the size of the log files in the Event Viewer to accommodate an increase in logging activity.

Weekly Maintenance

Maintenance procedures that require slightly less attention than daily checking are categorized in a weekly routine and are examined in the following sections.

Checking Disk Space

Disk space is a precious commodity. Although the disk capacity of a Windows Server 2003 system can be virtually endless, the amount of free space on all drives should be checked daily. Serious problems can occur if there isn't enough disk space.

One of the most common disk space problems occurs on data drives where end users save and modify information. Other volumes such as the system drive and partitions with logging data can also quickly fill up.

As mentioned earlier, lack of free disk space can cause a multitude of problems including, but not limited to, the following:

  • Application failures

  • System crashes

  • Unsuccessful backup jobs

  • Service failures

  • The inability to audit

  • Degradation in performance

To prevent these problems from occurring, administrators should keep the amount of free space to at least 25%.

Caution

If you need to free disk space, you should move or delete files and folders with caution. System files are automatically protected by Windows Server 2003, but data is not.

Verifying Hardware

Hardware components supported by Windows Server 2003 are reliable, but this doesn't mean that they'll always run continuously without failure. Hardware availability is measured in terms of mean time between failures (MTBF) and mean time to repair (MTTR). This includes downtime for both planned and unplanned events. These measurements provided by the manufacturer are good guidelines to follow; however, mechanical parts are bound to fail at one time or another. As a result, hardware should be monitored weekly to ensure efficient operation.

Hardware can be monitored in many different ways. For example, server systems may have internal checks and logging functionality to warn against possible failure, Windows Server 2003's System Monitor may bring light to a hardware failure, and a physical hardware check can help to determine whether the system is about to experience a problem with the hardware.

If a failure has occurred or is about to occur, having an inventory of spare hardware can significantly improve the chances and timing of recoverability. Checking system hardware on a weekly basis provides the opportunity to correct the issue before it becomes a problem.

Checking Archive Event Logs

The three event logs on all servers and the three extra logs on a DC can be archived manually, or a script can be written to automate the task. You should archive the event logs to a central location for ease of management and retrieval.

The specific amount of time to keep archived log files varies on a per-organization basis. For example, banks or other high-security organizations may be required to keep event logs up to a few years. As a best practice, organizations should keep event logs for at least three months.

The following script, named Logarchive.vbs, can retrieve event logs and store them in a central location. The process may take a long time (up to a few hours) depending on the size of the log files as well as how many servers you're pulling from. Avoid running this script over slow WAN connections so that bandwidth is conserved.

Set WS = CreateObject("Wscript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")

DateString = CurrentDate()
ServerName = "HOFS01"
Purge = True
on error resume next
StartTime = Now
Output "---------------------------------"
OutPut "Started at:  " + CStr(Now)
Output ""
Set System = GetObject("winmgmts:{(Backup,Security)}\\" + ServerName +
"\root\CIMV2")
If Err.Number = 0 Then
    Set colLogs = System.ExecQuery("select * from Win32_NTEventLogFile",,&H30)
For Each refLog In colLogs
            LogName = ServerName+ "_" + LogFileName(refLog.LogFileName) +
 "_" + DateString

    If FSO.FileExists("C:\Logs\" + LogName + ".evt") Then
 FSO.DeleteFile("C:\Logs\" + LogName + ".evt")
    If Purge Then
          RetVal = reflog.ClearEventlog("C:\Logs\" + LogName + ".evt")
          Else
              RetVal = reflog.BackupEventlog("C:\Logs\" + LogName + ".evt")
          End If
          If RetVal = 0 Then
              Output vbTab + "Log was archived in .evt format: " + LogName +
 ".evt"
              If Purge Then Output vbTab + "All events were cleared from
 the log"

          Else
                Output vbTab + "Error while archiving in .evt format."
          End If
    Next
Else
    Output vbTab + "Failed connect to the server"
End If
Set colLogs = Nothing
Set refLogs = Nothing
Set System = Nothing
Output "----------------------------------------"
OutPut "Finished at:  " + CStr(Now)
Output ""
Output ""
Set WS = Nothing
FullLog.Close
Set FullLog = Nothing
Set FSO = Nothing
Function CurrentDate
    Today = Date
    If Month(Today) < 10 Then
        CurrentDate = "0" + CStr(Month(Today))
    Else
        CurrentDate = CStr(Month(Today))
    End If
    If Day(Today) < 10 Then
        CurrentDate = CurrentDate + "0" + CStr(Day(Today))
    Else
        CurrentDate = CurrentDate + CStr(Day(Today))
    End If
    CurrentDate = CurrentDate + CStr(Year(Today))
    If Hour(Time) < 10 Then
        CurrentDate = CurrentDate + "0" + CStr(Hour(Time))
    Else
        CurrentDate = CurrentDate + CStr(Hour(Time))
    End If
End Function
Function LogFileName(LogName)
    Select Case LogName
        Case "Application"
            LogFileName = "app"
        Case "Directory Service"
            LogFileName = "dir"
        Case "DNS Server"
            LogFileName = "dns"
        Case "File Replication Service"
            LogFileName = "rep"
        Case "Security"
            LogFileName = "sec"
        Case "System"
            LogFileName = "sys"
    End Select
End Function
Sub Output(Text)
    wscript.echo text
    FullLog.writeline text
End Sub

Another file, logarchive.ini, is required when using logarchive.vbs. This file, shown next, contains a list of servers and the following archiving modes:

  • T means purge after archiving.

  • F means archive only.

    servername,T
servername,F
servername,F

To use logarchive.vbs, do the following:

1. | Verify that the logarchivelog.vbs and logarchive.ini files are in a pathed directory.
2. | Right-click the logarchive.ini file and type the list of servers on which you want to archive event logs.
3. | Choose Start, Run and type cmd to open a command prompt.
4. | At the command prompt, type cscript logarchive.vbs.

The command in step 4 archives all the event logs for the servers that were specified in the logarchive.ini file. The log files are stored in the directory specified in the script. Logs will be labeled in the following format:

servername_logname_date.log

For example, sfdc01_sec_02202003.log is the name for the SFDC01 server's Security log, archived on February 20, 2004.

It is recommended that you label log files in the following manner:

  • _sec_ Security log

  • _app_ Application log

  • _sys_ System log

  • _rep_ File Replication log

  • _dns_ DNS Server log

  • _dir_ Directory Service log

Note

logarchive.vbs does not purge the event logs.

Running Disk Defragmenter

Whenever files are created, deleted, or modified, Windows Server 2003 assigns a group of clusters depending on the size of the file. As file size requirements fluctuate over time, so does the number of groups of clusters assigned to the file. Even though this process is efficient when using NTFS, the files and volumes become fragmented because the file doesn't reside in a contiguous location on the disk.

As fragmentation levels increase, as illustrated in Figure 22.14, disk access slows. The system must take additional resources and time to find all the cluster groups in order to use the file. To minimize the amount of fragmentation and give performance a boost, the administrator should use Disk Defragmenter to defragment all volumes. As mentioned earlier in the chapter, Disk Defragmenter is a built-in utility that can analyze and defragment volume fragmentation. Fragmentation negatively affects performance because files aren't efficiently read from disk.

Figure 22.14. Disk Defragmenter tool.

[View full size image]

To use Disk Defragmenter, do the following:

1. | Start Disk Defragmenter by choosing Start, Programs, Accessories, System Tools.
2. | Select the drive to either analyze or defragment.
3. | Click either the Analyze or Defragment button to begin the defragmentation process. Note that simply selecting the Defragment button will automatically analyze the drive before proceeding with the defragmentation process.

Tip

Disk Defragmenter included in Windows Server 2003 is a scaled-down version of Diskeeper. Using a third-party defragmentation product, such as Diskeeper, enables you to schedule defragmentation during nonpeak hours. Many other features of third-party products, such as defragmenting servers remotely, would greatly benefit a company.

Running the Domain Controller Diagnostic Utility

The Domain Controller Diagnostic (DCDIAG) utility provided in the Windows Server 2003 Support Tools is used to analyze the state of a domain controller (DC). It runs a series of tests, analyzes the state of the DC, and verifies different areas of the system, such as

  • Connectivity

  • Replication

  • Topology integrity

  • Security descriptors

  • Netlogon rights

  • Intersite health

  • Roles

  • Trust verification

DCDIAG should be run on each DC on a weekly basis or as problems arise. DCDIAG's syntax is as follows:

[View full width]
dcdiag.exe /s:<Domain Controller> [/u:<Domain>\<Username> /p:*|<Password>|""] [/h:
  {parameter}] [/q:{parameter}] [/v:{parameter}] [/n:<Naming Context>] [/f:<Log>] [/
  ferr:<Errlog>][/skip:<Test>] [/test:<Test>]

Parameters for this utility are

  • /h Display this help screen.

  • /s Use <Domain Controller> as the home server. This is ignored for DCPromo and RegisterInDns tests, which can only be run locally.

  • /n Use <Naming Context> as the naming context to test. Domains may be specified in NetBIOS, DNS, or distinguished name (DN) format.

  • /u Use domain\username credentials for binding with a password. Must also use the /p option.

  • /p Use <Password> as the password. Must also use the /u option.

  • /a Test all the servers in this site.

  • /e Test all the servers in the entire enterprise. This parameter overrides the /a parameter.

  • /q Quiet; print only error messages.

  • /v Verbose; print extended information.

  • /i Ignore; ignore superfluous error messages.

  • /fix Fix; make safe repairs.

  • /f Redirect all output to a file <Log>; /ferr will redirect error output separately.

  • /ferr:<ErrLog> Redirect fatal error output to a separate file <ErrLog>.

  • /c Comprehensive; run all tests, including nondefault tests but excluding DCPromo and RegisterInDNS. Can use with /skip.

  • /skip:<Test> Skip the named test. Do not use in a command with /test.

  • /test:<Test> Test only the specified test. Required tests will still be run. Do not use with the /skip parameter.

Valid tests that can be run include the following:

  • Connectivity Tests whether DCs are DNS registered, pingable, and have LDAP/RPC connectivity.

  • Replications Checks for timely replication between domain controllers.

  • Topology Checks that the generated topology is fully connected for all DCs.

  • CutoffServers Checks for servers that won't receive replications because their partners are down.

  • NCSecDesc Checks that the security descriptors on the naming context heads have appropriate permissions for replication.

  • NetLogons Checks that the appropriate logon privileges allow replication to proceed.

  • Advertising Checks whether each DC is advertising itself and whether it is advertising itself as having the capabilities of a DC.

  • KnowsOfRoleHolders Checks whether the DC thinks it knows the role holders of the five FSMO roles.

  • Intersite Checks for failures that would prevent or temporarily hold up intersite replication.

  • FsmoCheck Checks that global roles are known, can be located, and are responding.

  • RidManager Checks to see whether RID master is accessible and whether it contains the proper information.

  • MachineAccount Checks to see whether the machine account has the proper information. Use the /RecreateMachineAccount parameter to attempt a repair if the local machine account is missing. Use /FixMachineAccount if the machine's account flags are incorrect.

  • Services Checks to see whether DC services are running on a system.

  • OutboundSecureChannels Verifies that secure channels exist from all the DCs in the domain to the domains specified by /testdomain. The /nositerestriction parameter will prevent the test from being limited to the DCs in the site.

  • ObjectsReplicated Checks that machine account and DSA objects have replicated. You can use /objectdn:<dn> with /n:<nc> to specify an additional object to check.

  • frssysvol Checks that the file replication system (FRS) SYSVOL is ready.

  • kccevent Checks that the Knowledge Consistency Checker is completing without errors.

  • systemlog Checks that the system is running without errors.

  • DCPromo Tests the existing DNS infrastructure for promotion to the domain controller.

  • RegisterInDNS Tests whether this domain controller can register the Domain Controller Locator DNS records. These records must be present in DNS for other computers to locate this domain controller for the <Active_Directory_Domain_DNS_Name> domain. Reports whether any modifications to the existing DNS infrastructure are required. Requires the /DnsDomain:<Active_Directory_Domain_DNS_Name> argument.

  • CheckSDRefDom Checks that all application directory partitions have appropriate security descriptor reference domains.

Note

Topology, CutoffServers, and OutboundSecureChannels are not run by default.

Monthly Maintenance

It is recommended that you perform the tasks examined in the following sections on a monthly basis.

Maintaining File System Integrity

CHKDSK scans for file system integrity and can check for lost clusters, cross-linked files, and more. If Windows Server 2003 senses a problem, it will run CHKDSK automatically at startup.

Administrators can maintain FAT, FAT32, and NTFS file system integrity by running CHKDSK once a month. To run CHKDSK, do the following:

1. | At the command prompt, change to the partition that you want to check.
2. | Type CHKDSK without any parameters to check only for file system errors.
3. | If any errors are found, run the CHKDSK utility with the /f parameter to attempt to correct the errors found.
Testing the UPS

An uninterruptible power supply (UPS) can be used to protect the system or group of systems from power failures (such as spikes and surges) and keep the system running long enough after a power outage so that an administrator can gracefully shut down the system. It is recommended that an administrator follow the UPS guidelines provided by the manufacturer at least once a month. Also, monthly scheduled battery tests should be performed.

Validating Backups

Once a month, an administrator should validate backups by restoring the backups to a server located in a lab environment. This is in addition to verifying that backups were successful from log files or the backup program's management interface. A restore gives the administrator the opportunity to verify the backups and to practice the restore procedures that would be used when recovering the server during a real disaster. In addition, this procedure tests the state of the backup media to ensure that they are in working order and builds administrator confidence for recovering from a true disaster.

Updating Automated System Recovery Sets

Automated System Recovery (ASR) is a recovery tool that should be implemented in all Windows Server 2003 environments. It backs up the system state data, system services, and all volumes containing Windows Server 2003 system components. ASR, shown in Figure 22.15, replaces the Emergency Repair Disks (ERDs) used to recover systems in earlier versions of Windows.

Figure 22.15. The ASR utility.

[View full size image]

After building a server and any time a major system change occurs, the ASR sets (that is, the backup and floppy disk) should be updated. Another best practice is to update ASR sets at least once a month. This keeps content in the ASR sets consistent with the current state of the system. Otherwise, valuable system configuration information may be lost if a system experiences a problem or failure.

To create an ASR set, do the following:

1. | Open Windows Server 2003's Backup utility by choosing Start, Programs, Accessories, System Tools.
2. | Click Advanced Mode from the first screen in the Backup or Restore Wizard.
3. | Click the Automated System Recovery Wizard button.
4. | Click Next in the Automated System Recovery Preparation Wizard window.
5. | Select the backup destination and then click Next to continue.
6. | Click Finish when you're done.

Note

This process might take a while to complete, so be patient. Depending on the performance of the system being used and the amount of information to be transferred, this process could take several minutes to a few hours to complete.

Updating Documentation

An integral part of managing and maintaining any IT environment is to document the network infrastructure and procedures. The following are just a few of the documents you should consider having on hand:

  • Server build guides

  • Disaster recovery guides and procedures

  • Checklists

  • Configuration settings

  • Change configuration logs

  • Historical performance data

  • Special user rights assignments

  • Special application settings

As systems and services are built and procedures are ascertained, document these facts to reduce learning curves, administration, and maintenance.

It is not only important to adequately document the IT environment, but it's often even more important to keep those documents up to date. Otherwise, documents can quickly become outdated as the environment, processes, and procedures change as the business changes.

Quarterly Maintenance

As the name implies, quarterly maintenance is performed four times a year. Areas to maintain and manage on a quarterly basis are typically fairly self-sufficient and self-sustaining. Infrequent maintenance is required to keep the system healthy. This doesn't mean, however, that the tasks are simple or that they aren't as critical as those tasks that require more frequent maintenance.

Checking Storage Limits

Storage capacity on all volumes should be checked to ensure that all volumes have ample free space. Keep approximately 25% free space on all volumes.

Running low or completely out of disk space creates unnecessary risk for any system. Services can fail, applications can stop responding, and systems can even crash if there isn't plenty of disk space.

Changing Administrator Passwords

Administrator passwords should, at a minimum, be changed every quarter (90 days). Changing these passwords strengthens security measures so that systems can't easily be compromised. In addition to changing passwords, other password requirements such as password age, history, length, and strength should be reviewed.

Maintaining the AD Database

AD is the heart of the Windows Server 2003 environment. Objects such as users, groups, OUs, and more can be added, modified, or deleted from the AD database. This interaction with the database can cause fragmentation. Windows Server 2003 performs online defragmentation nightly to reclaim space in the AD database; however, the database size doesn't shrink unless offline defragmentation is performed. Figure 22.16 shows the differences in fragmented versus defragmented AD databases.

Figure 22.16. Fragmented versus defragmented AD databases.

[View full size image]

NTDSUTIL is the tool for maintaining AD databases. It is used to defragment the AD database, but it also performs other routines such as cleaning up metadata left behind by abandoned domain controllers and managing Flexible Single Master Operations (FSMO).

Note

Compacting the AD database requires the DC to be rebooted.

To use NTDSUTIL to defragment the AD database, do the following:

1.
Restart the DC.

2.
When the initial screen appears, press the F8 key.

3.
From the Windows Advanced Options menu, select Directory Services Restore Mode (Windows domain controllers only).

4.
In the next screen, select the Windows Server 2003 operating system being used.

5.
Log on to the Windows Server 2003 system.

6.
Click OK when the informational message appears.

7.
At a command prompt, type NtdSUTIL files.

8.
At the File Maintenance prompt, type compact to %s, where %s identifies an empty target directory. This invokes Esentutl.exe to compact the existing database and write to the specified directory. The compaction process is illustrated in Figure 22.17.

Figure 22.17. Using the NTDSUTIL.

[View full size image]

9.
If compaction was successful, copy the new ntds.dit file to %systemroot%\NTDS and delete the old log files found in %systemroot%\NTDS.

10.
Type quit twice to exit the utility.

11.
Restart the computer.

Other uses for the NTDSUTIL include, but aren't limited to, the following:

  • Info Analyzes and reports the free space, reads the Registry, and then reports the sizes of the database and log files.

  • Integrity Performs an integrity check on the database, which detects any kind of low-level database corruption. This can take a long time to process if the AD database is large. It's important to note that you should always run Recover prior to running an integrity check.

  • Recover Attempts to perform a soft recovery of the database. This task scans the log files and ensures all committed transactions therein are also reflected in the data file.

MMC 3.0

MMC 3.0 is a natural evolution in the Microsoft Management Console line. It integrates seamlessly with the new WinRM toolset to provide powerful tools for system management. MMC 3.0 offers a similar look and feel with some additional features. The first is the Action Pane. It appears on the ride side of the frame and lists all actions that are possible for the selected item. This is a much appreciated feature and decreases down time looking for functions. There is also a new Add or Remove Snap-in Wizard that gives options for MMC 3.0 snap-ins and allows nested display. Finally, this new version adds improved error correction for faults in snap-ins that can cause the MMC to fail.

MMC 3.0 works in conjunction with .Net 2.0 and allows C# developers much freedom in creating their own snap-ins for Microsoft, and even for custom applications. This piece finally closes the loop between developers and the operational staff who support an application once it moves to the production stage.

Microsoft plans a roadmap for migrating current snap-ins to the MMC 3.0 structure and adding additional functionality to current tools.


Summary of Maintenance Tasks and Recommendations

Table 22.3 summarizes some of the maintenance tasks and recommendations examined in this chapter.

Table 22.3. Windows Server 2003 Maintenance Tasks

Daily

Weekly

Monthly

Quarterly

Tasks and Servers Accessed for Task Completion

Requires Server Downtime?

X

Check overall server functionality (login, access services, and so on)

No

X

Verify that backups are successful

No

X

Monitor Event Viewer

No

X

Check disk space

No

X

Verify hardware

No

X

Archive event logs

No

X

Run Disk Defragmenter

No

X

Run the Domain Controller

No

Diagnostic Tool (DCDIAG.exe)

X

Test the UPS

X

Run CHKDSK

Yes, if errors are found

X

Validate backups and restores

No

X

Update documents

No

X

Check disk space

No

X

Change administrator passwords

No

X

Run offline defrag of NTDS.DIT

Yes


Summary

Although administrators can easily get caught up in daily administration and firefighting, it's important to structure system management and maintenance to help prevent unnecessary amounts of effort. Following a management and maintenance regimen reduces administration, maintenance, and business expenses while at the same time increasing reliability, stability, and security.


Best Practices

  • Try to maintain the network environment's systems periodically to avoid any inefficiency.

  • Manage servers based on their roles and responsibilities.

  • Audit not only to identify security breaches or suspicious activity, but also to gain insight into how the network, network devices, and systems are accessed.

  • Enable audit policies through the local system policy or Group Policy Objects.

  • Remotely manage a system using Microsoft Management Console (MMC), Remote Desktop for Administration, scripting, and command-line utilities.

  • Use MOM to proactively manage Windows Server 2003.

  • Identify tasks that are important to the system's overall health and security.

  • Perform the first WINS backup to initiate automatic WINS backups.

  • Thoroughly test and evaluate service packs and updates in a lab environment before installing them on production servers and client machines.

  • Install the appropriate service packs and updates on each production server and client machine to keep all systems consistent.

  • Use Software Update Services to minimize administration, management, and maintenance associated with keeping up with the latest service packs and updates.

  • Distribute the service packs and hotfixes downloaded from SUS to a lab server for testing.

  • Categorize and document daily maintenance activities such as checking server functionality, verifying that backups were successful, and monitoring Event Viewer events.

  • Categorize and document weekly maintenance processes and procedures such as checking disk space, verifying hardware operation, archiving event logs, defragmenting volumes, and diagnosing domain controllers with DCDIAG.

  • Categorize and document monthly maintenance processes and procedures such as maintaining file system integrity, testing UPS functionality, validating backups, updating ASR sets, and updating documentation.

  • Categorize and document quarterly maintenance processes and procedures such as checking storage limits, changing administrative passwords, and maintaining the AD database.


Chapter 23. Automating Tasks Using Windows Server 2003 Scripting

In This Chapter

  • Scripting Overview

  • Introduction to VBScript

  • Active Directory Scripting Overview

  • Discovering Object Properties

  • Scripting User Management

  • Creating a User from File Data

  • Searching Active Directory

  • Windows Server 2003 Scripting

  • Leveraging Sample Scripts

Microsoft Windows Server 2003 supports performing server management and administrative tasks from both a command line and a graphical user interface. In many cases, these tasks are repetitive and are performed manually. For example, checking each server in a site and manually recording disk volume free space are single tasks on a maintenance checklist. Other manual tasks include creating users and changing group membership. Many tasks associated with server, workstation, or user management can be automated using scripts.

This chapter describes technologies that are used for scripting, including some command-line utilities and scripts written using the Microsoft Visual Basic Scripting language known as VBScript. This chapter also covers some basic scripting commands and provides some examples using WMI, ADO, CDO, and ADSI object models to manage the Windows Server 2003 environment. The purpose of this chapter is to help administrators think of ways to simplify administrative tasks by creating scripts.


Scripting Overview

When a project or task involving scripting comes around, many administrators cringe at the thought. Administrators new in the IT field associate scripting with programming or creating applications. In many instances, that is the case. However, many administrators may already be using or even creating scripts although they disregard such scripts simply because they were too easy to create or did not have loops of code or fancy output. For example, many administrators create login scripts but don't consider this task to be scripting because the scripts may just be simple batch files to map network drives. If a file automatically executes several commands sequentially or simultaneously, it is a script.

Scripting should not be categorized only as programming unless the use of the script defines it that way. Scripts can be created to break down large or complicated processes into many simple tasks, such as a checklist that can be followed to step someone through the entire process. A good example of a script unrelated to computing and networking is a cooking recipe. If you follow the steps in the recipe, the result could bring a delicious meal. A script that automates the process of creating several hundred user accounts can reduce the time necessary to complete the task and also reduce human error because the input data can be read from a file as opposed to being typed manually.

IT administrators can configure a number of scripts that provide some level of automation when it comes to managing hardware, software, groups, and user accounts within an organization. Scripts can be classified in a number of ways, such as documented instruction guides, server management scripts, workstation management scripts, directory management scripts, and application management scripts. Users may also have separate configuration scripts, including logon and logoff scripts.

Documented Instruction Scripts

A documented instruction script is generally fairly basic in nature. Usually, this script is used by administrators, end users, or personnel as an instruction guide or a step-by-step script that needs to be followed to perform a task. For example, this type of script could test an application's functionality; it may also be called a quality assurance script. The following script, for example, can be used by help desk personnel to verify basic operation of the domain name system:

1. | Log on to a server or workstation with access to the network with the DNS server.
2. | Choose Start, Run.
3. | Type cmd.exe and click OK to open a command prompt.
4. | Type Nslookup and press Enter.
5. | Type Server followed by the name of the DNS server you want to test. For example, type Server ns1.companyabc.com. Then press Enter.
6. | Type in an Internet record, such as www.microsoft.com, and press Enter.
7. | If an answer is displayed, type quit. Then type exit to close the command prompt.

Although the preceding is really just a step-by-step guide, it is also a script, executed manually. It is a script that checks whether the DNS server can resolve Internet DNS records.

These types of scripts, depending on the skill levels of your staff and the scope of the document, may best be created by IT staff and then formatted, standardized, and cleaned up by a technical writer. One of the biggest factors for scripted instructions is the level of detail necessary. This detail is defined by the target audience. For example, if the preceding script were written for an administrator with a reasonable amount of knowledge with DNS, the script may simply be:

Perform a DNS lookup of an external Internet address using ns1.companyabc.com to verify Internet name resolution.

The steps here are presented so that a person who has only basic computer skills can perform the task.

Common scripts that organizations may benefit from are those that shut down and restart a server. Back in the days when remote server management was very limited, if a server crashed and the administrator was not onsite, this type of document could assist onsite personnel in completing the necessary task of rebooting the server instead of having to wait for the administrator to return.

Server Management

Server management scripts come in a few flavors. Scripts can be written to collect information stored in the Registry, on the hard drive, or in the BIOS. Information such as how long the server has been running, how much free disk space remains, and how many users are using applications and services such as file shares, printers, or terminal server sessions can be collected and analyzed. Files and printer shares can be created and configured remotely without user intervention, and NTFS permissions can be checked and updated using a script.

A script can be created to connect to a server or list of servers, and each server can be shut down, rebooted, or have a service restarted. There are really few limitations on what can be performed on a server using a script. For the most functionality when it comes to managing Windows Server 2003 systems, Microsoft Windows Management Instrumentation (WMI) may provide the most extensive functionality.

Workstation Management

Workstation management is not really different from server management in the way scripts can be used. Tasks that can be performed on workstations rather than on servers are updating security patches and restarting a number of machines. Other examples might be sending out pop-up messages to all workstations on the network that will be affected by a server that is going offline, or telling users to save data before battery backup power runs out during an extended power outage.

Scripts for User Configuration

Scripts to manage users include logon and logoff scripts primarily. Logon and logoff scripts can be used to connect and disconnect network printers and network file shares, clear out old temporary files, or save data stored in a local folder up to the server. Advanced features of logon scripts can include incorporating command-line executables and Visual Basic Script commands to connect to resources based on group membership, create email profiles, configure instant messenger settings, and record logon and logoff statistics.

Directory Administration Scripts

Directory administration scripts can perform many tasks that benefit administrators at all levels of the IT hierarchy. Script usage can include searching directories, creating user accounts, adding members to groups, and much more. To manage user objects in a directory, you can create a script to scan the directory for locked-out or disabled user accounts. Scripts can check whether new accounts were created during a certain period of time and determine which accounts they are.

Some commonly created directory administration scripts include scripts to read from files for directory imports and create output files to update separate directories. User information can be synchronized or overwritten from information stored in separate directories. Objects that commonly are synchronized between directories are user objects and properties, and group objects and their members.

Many organizations create directory scripts to give lower-level administrators and end users a way to manage and access their particular directory object or set of objects. For example, a script could be written for an employee in the Human Resources department who needed to have the ability to create user accounts and modify contact information for all existing employees in the directory. Without the benefit of scripting, this process would have to be performed by loading the administrative tools on the HR user's desktop and then training him how to create users and how to locate users using the tool. This would be a tedious alternative and would give the user access to more information than is necessary.

A better alternative would be creating a few simple scriptsone to create a user and another to find an existing user in the directory. The scripts would be used to provide an HTML or Visual Basic interface for an HR manager to update employee contact data. Only minimal data would be necessary for user creation, and several fields can be populated from that information. For example, if two required fields were Location and Department, this data could be used to determine group membership, home folder server, profile location, and logon script. To simplify looking up or editing information, you can create pull-down menus to limit the HR manager's options. As an added bonus to the user creation script, the user account could be set to require a password change at next logon.

Advantages of Scripting

This chapter focuses on automating user management, computer management, and server administration tasks. The scripting language VBScript will be used throughout this chapter along with a few other technologies, including ActiveX Data Objects (ADO) and Windows Management Instrumentation (WMI). A few advantages of using scripts to perform repetitive or tedious tasks is that human error is reduced because scripts will never skip a step or incorrectly type in data when synchronizing information, or even worse, stop a service to perform a maintenance task and forget to start it up afterward. Scripts that will be deployed to automate tasks should be completely tested in a lab environment before being deployed in a production environment.


Introduction to VBScript

VBScript is one of the two scripting languages created by Microsoft. For the scripts in this chapter, VBScript will be used. It is not a replacement for a full programming language such as Visual Basic .NET or Visual C++ but is tailored to provide, in many cases, portable code that can be viewed, modified, and executed on any machine with a VBScript host or interpreter.

Unlike the so-called real programming languages that must be compiled before the system can understand the code, VBScript remains in plain text until actual runtime when the code is interpreted and executed on the system. VBScript commands are not recognized directly by the operating system, so they must be run using a VBScript host or interpreter that can convert the code so that the operating system can execute the commands. VBScript is portable and does not carry a lot of the overhead that can sometimes be associated with compiled applications such as DLL files and such. VBScript files can be run using the Windows Scripting Host (WSH) or be written into a Web page that supports scripting.

The file extension for a VBScript file is .VBS, and this extension is configured by default to run using Wscript.exe. This enables a VBS file to be double-clicked to run just like executable .EXE files. Another option is to run the files in a command-line environment using Cscript.exe.

Visual Basic Script Options

A Visual Basic script is not compiled code, so it must be run within a host or context that can interpret the commands and present them to the operating system so they are executed as desired. You can make sure VBScript code is processed by calling the code using the Windows Scripting Host or adding the code within HTML or ASP Web pages on Web servers that support the VBScript language. Also, before compiling the code, you can add VBScript code to Visual Basic or C-compatible applications to handle certain tasks or functions that can be performed with less code than VBScript.

Windows Scripting Host

Using the Windows Scripting Host, scripts written in VBScript or JScript can be interpreted at runtime and executed on a server or workstation. WSH supports running scripts from the command line using Cscript.exe and supports running scripts within the graphical user interface by using Wscript.exe. Both are part of the Windows Scripting Host program. To see the differences and to dive right into a simple script (recommended in a lab environment) using VBScript, follow these steps:

1.
Before you start creating scripts, create a directory called Scripts on the root of the C drive.

2.
Choose Start, Run. Type notepad.exe and click OK to create a new VBScript. To create the script, type the following code in the Notepad window, pressing Enter after each line:

Dim CurrentTime
CurrentTime = time
Wscript.echo "The current time is "& CurrentTime & "."

The Dim command declares a variable called CurrentTime that can be referenced throughout the rest of the code. The next line of code sets the CurrentTime variable to the value of the time function, which will give you the current time. The last command, Wscript.echo, will display the text enclosed in double quotation marks followed by the value of the CurrentTime variable. Notice the & symbol after the text and after the variable; it is used to tell the Wscript.echo command that there is still more information to echo and to continue writing to the same line.

3.
Save the file with a .VBS extension, using a name such as c:\Scripts\VBtime.vbs, and close Notepad.

4.
Choose Start, Run and then type cmd.exe to open a command prompt.

5.
Change directory to the c:\Scripts directory.

6.
Type Wscript.exe VBtime.vbs and press Enter. Note how the output is displayed as a pop-up window while Wscript.exe runs by default in the graphical user interface.

7.
Click OK to close the pop-up window and return to the command prompt.

8.
Type Cscript.exe VBtime.vbs and press Enter. Note how the output is displayed in the command-line interface and does not require user intervention to acknowledge the response the way Wscript.exe does.

The reason the same code returns the information in different ways is inherent to the Wscript.exe and Cscript.exe applications. The output is also directly related to the actual commands being called. For example, modify the VBtime.vbs script as follows, save the file, and run the script using both Wscript.exe and Cscript.exe:

Dim CurrentTime
CurrentTime = time
MsgBox "The current time is "& CurrentTime & "."

When this script is run using either Wscript.exe or Cscript.exe, the output is the same: a pop-up window displaying the current time. The reason for this result is that the message box (MsgBox) function is a graphic function, whereas the Wscript.echo command merely echoes output to the current interface.

Note

If a command such as Wscript.echo is used several times in a script, be sure to run the script using Cscript. Otherwise, user intervention will be necessary to close each pop-up window sequentially.

Active Server Pages

Active Server Pages (ASP) running on Windows Server 2003 Internet Information Services (IIS) enable Web developers to include scripting code within dynamic HTML pages. This can be client-side scripting that is downloaded and executed on the end user's machine or server-side scripting that is executed on the back-end server. Recently, because a few problematic viruses have been written using VBScript, many organizations now disable client-side VBScripting on their proxy servers and firewalls. In such cases, client-side scripting may not function correctly, so server-side scripting should be used. By default when a client chooses to view the source code, the script will not show up, only the returned values.

An ASP Web page can also be created using notepad.exe, but many developers use a program such as Microsoft FrontPage to simplify code creation. Different objects, object properties, and methods associated with VBScript can be used within an ASP Web page. For example, using the WSH, you displayed information to the console using Wscript.echo; but when you want to display information in a Web page, you use the response object and the write method of that object. To create an ASP Web page that will display the current time, follow these steps:

1.
Log on to an IIS server. Open Windows Explorer, and under the default Web site directory, create a folder called ASPscripts. Check to ensure that the Anonymous user account has access to this folder. It should have these permissions already because it will be inheriting permissions from the parent folder. The default location will be c:\inetpub\wwwroot.

2.
Choose Start, Run. Type notepad.exe and click OK to create a new VBScript. To create the script, type the following code in the Notepad window:

<HTML>
<HEAD>
<TITLE>
My ASP page Using Vbscript!
</TITLE>
</HEAD>
<BODY>
<P>
<%
DIM CurrentTime
CurrentTime = time
response.write "The current time is " & CurrentTime & "."
%>
</P>
</BODY>
</HTML>

3.
Save this file as C:\Inetpub\ASPscripts\VBtime.asp on the IIS server.

4.
To test the script, open Internet Explorer on the IIS server and type http://localhost/ASPscripts/VBtime.asp to see the output page, as shown in Figure 23.1.

Figure 23.1. A sample ASP Web page using VBScript.

Note

The Web site created in step 4 should already support Active Server Pages. To enable ASP.NET on this Web site, refer to the Help and Support menu. Also, refer to Chapter 11, "Internet Information Services v6."

The output of this ASP Web page is simple, but it can be extended using both HTML and VBScript commands. Also, you can use different scripting languages in a single ASP Web page if necessary. The code in this ASP is similar to the VBScript file previously written. Using ASP, though, you need to designate the beginning of the script code using <% and end of the code using %>. This will assume that the default scripting language VBScript is being used. To designate a different language such as JScript or JavaScript, refer to ASP documentation.


Active Directory Scripting Overview

To automate administrative tasks for Windows Server 2003 systems specifically aimed at managing Active Directory objects such as users, groups, and computers, VBScripts must use commands and references associated with predefined programming object models. A programming object model defines the hierarchy of an object, such as a user object in Active Directory or the directory structure itself. An object model defines which properties or attributes of an object can be accessed and also how the object is accessed or changed.

For example, an Active Directory user object has a property called SamAccountName. The value of this property is used as the user's logon name, and the SamAccountName property is accessed through the property's Get or Put methods. Active Directory Services Interface (ADSI) provides the Get, GetEx, and GetInfo methods to connect or read data from Active Directory or an Active Directory object. To create or modify an object and its properties, a script would reference the Put, PutEx, or SetInfo method. Microsoft provides several object models that, in some cases, overlap in functionality, but they are usually tailored to provide an interface to a particular type of resource or object.

Active Directory Objects

Active Directory has a few objects that regular administrators will need to access and manage. For example, users, groups, computers, and contact objects will need to be managed to set security, make configuration changes, or add or remove members from groups. To access these objects and read or set values on particular object's properties, VBScript needs to connect to that object or objects using a specific interface that provides the access.

The interface is commonly referred to as the application programming interface (API), which contains one or several programming object models that can be referenced through it. As an example, the Active Directory Services Interface provides access to an Active Directory user object using a built-in, predefined user object model. The ADSI user object model provides the ability to access most of the user properties. The object properties available are usually defined by what properties are available for that object, as defined in the Active Directory Schema. The Active Directory Schema defines all properties an object could ever have. It defines which properties are mandatory and must be defined before a new object can be created, and it defines the characteristics of object properties. For example, a user object property of Last Name is an optional attribute. If populated, it will need to have at least one character but no more that 128 as defined in the Active Directory Schema.

To access and modify all the attributes on Active Directory objects, you can use several different application programming interfaces and programming object models to manage the entire directory or a single directory object. After the next few sections cover frequently used object and directory interfaces, we will provide and outline a few sample scripts to show how different technologies can be used when you need to script an administrative task. Half the battle associated with scripting is knowing which object models and interfaces can be used to perform the task or access the desired object in the directory. After the use of the interface is revealed, it is only a matter of finding the property names and the methods available to manipulate the object properties.

Active Directory Services Interface

ADSI is a directory service model that was developed to create a single interface to access and modify directories and directory objects. ADSI supports several directories such as Microsoft Exchange 5.5, Novell NetWare NDS, and Microsoft Active Directory. Using ADSI, you can automate many directory-related tasks, such as creating users or dynamically adding or removing members from groups. ADSI will be used in conjunction with ADO, CDO, WMI, and VBScript when devices in the enterprise need to be located and when directory objects need to be created or modified.

Working with Active Directory Objects

Active Directory objects can be created, deleted, or modified using scripts. Before any object can be accessed, a connection to the directory must first be established. You perform this task by presenting a directory services path to the directory container using a standard protocol. For example, to connect to Active Directory, you can use the LDAP protocol to connect and use ADSI to specify the directory container object to connect to. By using the string "LDAP://CN=Users,DC=Companyabc,DC=com", you can use a specific ADSI method called Get to connect to the Users container in the Companyabc.com domain. When the connection or binding is established, the container can be queried for a list of computers, users, or groups; or new objects can be created. The initial binding to the directory determines the root starting point for directory searches and sets the level of permission granted to the directory, which is based on the user context in which the script is run.


Discovering Object Properties

When Active Directory objects are discussed, the terms object properties and object attributes are frequently used. Sometimes the two can be interchanged. Depending on the interface used to access the object, though, this may not be the case. To make things more confusing, when the Active Directory Users and Computers MMC snap-in is used to view or change a user's attribute values, the friendly name presented in the graphical user interface may not be the same as the actual directory name. For example, on a user's Address property page, there is a field labeled City. Accessing this user object directly using ADSI Edit, the directory name for the City field is "l," which stands for "location," as shown in Figure 23.2.

Figure 23.2. Accessing Active Directory user objects.

To discover the directory names of object attributes and to find out what possible attributes an object can contain, you can use two utilities to simplify this task. The Active Directory Users and Computers MMC snap-in can also provide a roundabout way to find object attributes using the Saved Queries applet.

The directory name of an object's attribute is used in a script when the script attempts to read or update the attribute's value. To find the directory name of an attribute, you may find the ADSI Edit MMC snap-in to be the easiest tool to use.

ADSI Edit MMC Snap-in

The ADSI Edit MMC snap-in provides a direct peek into Active Directory partitions to view and modify the objects contained within. ADSI Edit helps you figure out the actual directory names and values of objects and their attributes.

Caution

ADSI Edit is to Active Directory as Registry Editor is to the System Registry. ADSI Edit is a very powerful tool, but it's important to keep in mind that it doesn't have built-in safeguards that make Active Directory Users and Computers a relatively idiot-proof application. For example, ADUC doesn't allow having more than one primary SMTP address for a user account. There is nothing in ADSI Edit that prevents from assigning multiple primary SMTP addresses, and that may cause serious problems. Changes can be irreversible without a restore from backup. Therefore, perform a full backup prior to working with ADSI Edit.

You can use ADSI Edit to manually populate object attributes when the attribute is not readily available using the Active Directory Users and Computers MMC snap-in. This snap-in can be handy when an attribute name is not known. The entire list of attributes can be displayed in a single window within the snap-in. To connect to the Active Directory Domain Naming Context partition, perform the following steps:

1.
Log on to a workstation or server with Domain Admin rights and Local Admin rights on the machine.

2.
Install the Windows Server 2003 support tools from the setup CD-ROM. You can install the support tools by running the setup program D:\Support\Tools\ SUPTOOLS.msi, where D represents the letter assigned to the CD-ROM if the setup CD-ROM is used.

3.
After the support tools are installed, choose Start, Run.

4.
Type MMC and click OK to open the Microsoft Management Console.

5.
Choose File, Add/Remove Snap-in.

6.
In the Add/Remove Snap-in window, click the Add button to bring up a list of available snap-ins.

7.
On the Add Standalone Snap-in page, select ADSI Edit Snap-in and click Add.

8.
When the ADSI Edit snap-in is listed in the Add/Remove Snap-in window, click Close on the Add Standalone Snap-in page and click OK in the Add/Remove Snap-in window.

9.
When you're back in the MMC window, right-click the ADSI Edit applet and select Connect To.

10.
Enter the Active Directory partition or a container's distinguished name as the connection point. To connect to the entire domain so that you see a view similar to Active Directory Users and Computers, click the radio button labeled Select A Well Known Naming Context. Then choose the domain naming context, as shown in Figure 23.3.

Figure 23.3. Selecting the domain naming context as the initial connection point.

11.
In the Computer section, choose to specify a domain or server or choose the default domain.

12.
Click OK to create the connection.

13.
Choose File, Save.

14.
Save the console as ADSI Edit in the suggested location and click the Save button.

15.
In the console window, expand the domain partition to find objects within the containers in the Active Directory domain.

Discovering the Directory Name of a User Attribute

To find the directory name of a particular user attributefor example, the Pager attributefollow this simple process:

1. | Using the Active Directory Users and Computers MMC snap-in, find a test user that can be manipulated. Populate the Office attribute on the user's General property page using something that will be easy to locate, such as ZZZZ. Save the change and close the user object.
2. | After you save the value, open ADSI Edit by choosing Start, All Programs, Administrative Tools, ADSI Edit. If the console does not appear, perform the steps outlined in the preceding section to create the console.
3. | Browse the directory to locate the correct user object.
4. | Right-click that user and select Properties.
5. | In the Attribute Editor page, click the button labeled Values in the window. This will sort the list of attributes based on the value string, with numbers followed by an alphabetical listing.
6. | Scroll to the bottom to find the value ZZZZ.
7. | Note the particular attribute name associated with the page value.
8. | If the value cannot be located, close the window, right-click the object, choose Refresh, and then open the properties again.

By using the Active Directory Users and Computers MMC snap-in, you find the attribute labeled Office actually has a directory name of PhysicalDeliveryOfficeName. If a script were trying to find this information referencing an attribute called Office, the script would always generate an error.

Active Directory Schema MMC Snap-in

The Active Directory Schema MMC snap-in is a powerful tool that can be used to modify and extend the Active Directory Schema. You can also use it to view and modify the characteristics of directory objects and attributes. For example, if a script will be used to populate a user object's Pager attribute, by using the Schema MMC snap-in, you can locate the Pager attribute to view attribute settings such as what type of data can be stored in this attribute, minimum and maximum range of characters it can support, and whether the attribute is single valued or multivalued.

To create and use a Schema MMC snap-in, follow these steps:

1. | Log on to a workstation or server with Domain Admin rights and Local Admin rights on the machine.
2. | If you're using a Windows Server 2003 system, proceed to step 4.
3. | Install the Windows Server 2003 Administration pack from the setup CD. The Administration pack can be installed on Windows XP Professional systems. Install it by running the setup program D:\i386\Adminpak.MSI, where D represents the letter assigned to the CD-ROM if the setup CD-ROM is used.
4. | After you install the Administration pack, choose Start, Run.
5. | Type the command Regsvr32.exe schmmgmt.dll and click OK. A confirmation popup window should appear, stating that the file has been registered correctly. This makes the Schema MMC snap-in available for use. Click OK to close this pop-up confirmation window.
6. | Choose Start, Run.
7. | Type MMC and click OK to open the Microsoft Management Console.
8. | Choose File, Add/Remove Snap-in.
9. | In the Add/Remove Snap-in window, click the Add button to bring up a list of available snap-ins.
10. | On the Add Standalone Snap-in page, select Active Directory Schema Snap-in and click Add.
11. | When the Active Directory Schema snap-in is listed in the Add/Remove Snap-in window, click Close in the Add Standalone Snap-in page. Then click OK in the Add/Remove window.
12. | Choose File, Save.
13. | Save the console as Schema in the suggested location and click the Save button.

After you create the Schema MMC snap-in, you can review objects to understand which attributes are available for each object. For example, to find out the characteristics of a Pager attribute, follow these steps:

1. | If the Schema MMC snap-in is not open already, choose Start, All Programs, Administrative Tools and select Schema.msc. This, of course, assumes that the console was created as outlined in the preceding steps. Otherwise, open MMC and add the Schema MMC snap-in. Note When connected, Domain Administrators can view the Schema using this tool, but only members of the Schema Admins group can make modifications to object classes or attributes.
2. | Select the Attributes container in the left pane; then in the right pane, scroll down and select Pager. If you don't know the directory name of the desired attribute, refer to the "Discovering the Directory Name of a User Attribute" section earlier in this chapter.
3. | Right-click the Pager attribute and select Properties to open a window showing the attribute properties.
4. | If you need to change somethingfor example, if this attribute should be indexed in the global catalog to improve searches for pager numbersyou can make that change using this window. Only members of the Schema Admins group can make this change. Close this window and the Schema MMC snap-in when you're finished.

By using the Schema MMC snap-in, you can extend the Active Directory by adding new attributes that can be placed in specific classes, such as the user class. Extending the schema is beyond the scope of this chapter. For more information on extending the schema in a Windows Server 2003 forest of domains, refer to the Help and Support menu on a Windows Server 2003 server. This menu will also scan the Microsoft Knowledge Base on the Internet for relevant articles if the server has such access.


Scripting User Management

Scripts to manage Active Directory users include features such as creating users, searching AD containers to get a list of users, and changing user attribute values for existing users. For the particular user object in AD, mandatory and optional attributes are available.

Each mandatory attribute must have a value in order for the user to be created. Every user will have a value for each mandatory attribute. When searching for a user, you should use these primary attributes. For example, a mandatory user attribute is the SamAccountName attribute. If you want to create a list of user logon names, you can query the domain for user objects and request the value of the SamAccountName attribute for each user object.

An optional attribute could be a user's pager or telephone number. Locating users based on optional attributes could be effective only if you want to filter a search. For example, if you want to create a list of users in the domain with a last name of Smith, you can get a list of all the users using the SamAccountName attribute, query the last name value, and then compare it to Smith. The list returned would be only users whose last name matches the criteria.

Note

The Last Name field has a directory name of sn, representing surname.

Scripting User Creation

To create a new AD user using ADSI and VBScript, you can break down the process into these four simple steps:

1. | Connect to the directory or specific container object.
2. | Create the user by populating the mandatory attributes.
3. | Populate additional attributes and update the user object.
4. | Exit the script.

To access an Active Directory user object, you use ADSI, but to perform a search, you use ADO. If exchange attributes need to be populated, you use CDO. To create a user, you need to populate one of the mandatory attributes, the CN attribute, at creation. This attribute contains the value that will be used to create the DN, or distinguished name, of the user object. To create a user creation script, type the following code in a new text file using Notepad:

set obj= GetObject("LDAP://cn=users,dc=companyabc,dc=com")
set usr = obj.Create("user","cn="& "TestUser")
usr.SetInfo

Now follow these steps to continue the process:

1. | Save the file as ADuser.vbs in the C:\Scripts directory, which will be used to store scripts.
2. | Choose Start, Run.
3. | Type cmd.exe and click OK to open a command prompt.
4. | Type cscript c:\scripts\ADuser.vbs to execute the script in the command-line environment.

Note

The ADuser.vbs script will not work in this form if a password policy configured in the domain does not allow null passwords.

The ADuser.vbs script will create a user named TestUser in the Users container of the Companyabc.com domain. The first line of the code uses ADSI to connect to the Users container and essentially binds to it. The GetObject method does not specify authentication, so the script runs in the context of the logged-in user. The second line creates a user object in the Users container. The last line actually saves the changes to the directory container specified in the first line of code.

This very basic script, outlined previously, can be modified to connect to a specific organizational unit or even specify a domain controller. The initial connection line using the GetObject method, which uses what is called the ADSPath attribute of an object, is used to bind to the directory. If the initial ADS path to the container you are binding to is unknown, you cannot connect to it using ADSI. The ADSPath attribute is made up of the protocol binding format, followed by the object or container's DistinguishedName value. To find the DistinguishedName value of the Users container in the Companyabc.com domain, use ADSI Edit as outlined in the "ADSI Edit MMC Snap-in" section earlier in this chapter. Then follow these steps:

1.
Log on to the desired workstation or server with the appropriate level of permissions to open ADSI to browse the directory objects. Usually, membership in the Domain Admin group will suffice.

2.
Choose Start, All Programs, Administrative Tools, ADSI Edit. If the console does not appear, perform the steps outlined in the "ADSI Edit MMC Snap-in" section earlier in this chapter to create the console.

3.
Browse the directory to locate the user or container for which you want to find the DistinguishedName value.

4.
Right-click that object and select Properties.

5.
On the Attribute Editor tab, make sure both the Show Mandatory Attributes and the Show Optional Attributes boxes are checked.

6.
Scroll down in the window to find the DistinguishedName attribute and note the value, as shown in Figure 23.4, for the Users container of the Companyabc.com domain.

Figure 23.4. Locating the value of the DistinguishedName attribute for the Users container.

In this case, the DistinguishedName for the Users container is CN = Users,DC = companyabc,DC = com. The DC reference is used for the domain. Separate subdomains also use the DC reference. Organizational units use the OU reference. Users, groups, contacts, containers, computers, and other directory objects use the CN reference. This all comes from the ADSI object model. To use the distinguished name (DN) to construct an ADSPath value for connecting to Active Directory objects, simply add LDAP:// to the beginning of the DN value when referencing it in a script.

Populating Optional User Attributes

After you create a user in Active Directory, you can add optional attribute values. Expanding on the previous three-line user creation script, you can add more attributes after the user is created. The following script populates the pager and initial password attributes:

set obj= GetObject("LDAP://cn=users,dc=companyabc,dc=com")
set usr = obj.Create("user","cn="& "TestUser")
usr.pager = "999-999-9999"
usr.SetInfo
usr.setpassword ="mycleartextpassword"
usr.SetInfo

Save this file as a VBS file and run it using Cscript.exe, as shown in previous examples. The interesting aspect of this example is that the password is set only after the user is created because the user must first exist before the password can be set.

Populating User Attributes Using Variables

When you plan to create many users, populating attributes using data stored in variables can save you many hours. Expanding on the basic user creation script, you can set a user's logon script path using a variable. If you're writing a complicated script, using subroutines to perform basic tasks for each object, you will need to declare variables globally so that they can be referenced throughout the script. If a variable will be used only in a particular subroutine, the variable may need to be declared, or it can just be declared and used within that subroutine. To declare a variable and populate a user's profile path when creating the user, modify the previous script as follows:

Dim ProfilePth
ProfilePth = "companyabc.com\Profiles\%Username%"
set obj= GetObject("LDAP://cn=users,dc=companyabc,dc=com")
set usr = obj.Create("user","cn=" & "TestUser")
usr.pager = "999-999-9999"
usr.ProfilePath = ProfilePth
usr.SetInfo
usr.setpassword ="mycleartextpassword"
usr.SetInfo
ProfilePth = ""

The three lines added at the beginning declare the variable. Next, the variable is populated with a value. Three lines later, the ProfilePath attribute is set to the value stored in the ProfilePth variable. Finally, the last line in the script clears the contents of the variable.

Similar to ADSI Edit, ADSI scripting has almost no safeguards. In addition, since a single script can update thousands of user objects in a matter of seconds, there is a risk that a single misspelled character can cause disastrous results.

There are several things that can be done to minimize the risk of mass updates of AD attributes:

1. | Understand exactly what effect the changes will make.
2. | Test the script in the lab.
3. | Create an Active Directory Backup.
4. | Run the script on a limited scope of Active Directory objects (such as a single OU) before doing a full-scale attribute update.

Scripting Exchange 2000 Properties for Active Directory

When Exchange 2000 or Exchange 5.5 with the Active Directory Connector (ADC) is used with an Active Directory forest, the forest schema is extended to support the necessary attributes to give a user or group Exchange messaging attributes. To manipulate a user's messaging status or configuration, an administrator must use the programming object models made available with Collaborative Data Objects (CDO).

Collaborative Data Objects

CDO provides a programming interface and object model to manage Exchange 5.5 and 2000 server messaging objects using a script written in VBScript or a compiled application written in a programming language such as Visual Basic or Visual Ccompatible languages. CDO can be used to create public folders, add contacts to the Exchange address book, and create a user's mailbox. Scripts that create users in Active Directory can be easily modified to also give these users email addresses or mailboxes on an Exchange 2000 server. To create users and also mail-enable them, you could write a single script in VBScript that will connect to Active Directory using ADSI to create the user object and CDO to mail-enable the users. To mail-enable an Active Directory user in a forest that contains Exchange 2000 servers, follow these steps:

1.
Log on to the desired workstation or server with the appropriate level of permissions to completely administer user objects in Active Directory. This user account must also have a minimum of Exchange 2000 View Only Admin rights in the respective Exchange 2000 Administrative group. For more information on Exchange 2000 organizations and permissions, review Exchange 2000 documentation.

2.
If it has not already been installed on the system, install the Windows Server 2003 Adminpak.msi and install the Exchange 2000 System Tools. The Adminpack will be necessary to use tools such as the Active Directory Users and Computers MMC snap-in to review user status after the script has run. Installing the Exchange System Tools will install and register the CDO.dll so that the CDO object models can be used on this machine.

3.
To extend the user creation script and mail-enable the test user upon creation, create the following script:

set obj= GetObject("LDAP://cn=users,dc=companyabc,dc=com")
set usr = obj.Create("user","cn="& "TestUser")
usr.pager = "999-999-9999"
usr.SetInfo
usr.MailEnable "smtp:" & usr.cn & "@domain.com"
usr.setpassword ="mycleartextpassword"
usr.SetInfo

Using the preceding script will create a user, add a value to the Pager attribute, mail-enable this user (which means giving this user an external email address and adding a reference to the Exchange address book), and finally set the initial password.


Creating a User from File Data

Now that we have stepped through some very basic scripts, we can start tackling more complicated tasks such as creating users from file data. When data is presented to IT personnel for the purpose of creating several user accounts, this data can be referenced and used to help automate user creation. Commonly used file formats include LDIF-compatible files, comma-separated value (CSV) files, and tab-separated value (TSV) files. Files can be read with VBScript using the File System Object (FSO) model. If the files are presented in LDIF or CSV format, the data can be cleaned up and used to create users in Active Directory using either the Ldifde.exe tool or Csvde.exe tool, respectively. Also, if the data necessary to create the directory object is stored in a database or a separate directory, the data can be retrieved using ActiveX Data Objects (ADO) provided that ADO can bind to the database.

Using Ldifde.exe or Csvde.exe

Ldifde.exe and Csvde.exe are both great tools for creating directory objects using clean formatted data presented in LDIF or CSV format. As export tools, their functionality includes exporting data based on location in the directory, OU membership, and object class such as user, group, or computer; they also specify which attributes to export. As far as specifying certain attributes, these tools are fairly limited, but for one-time mass user export and import scripts, they can add value to directory management. To use Ldifde.exe to create an export file of every object in the Users container of Companyabc.com, follow these steps:

1.
Log on to a workstation or server in the Companyabc.com domain with an account that has Domain Admin rights.

2.
Choose Start, Run.

3.
Type cmd.exe and click OK to open a command prompt.

4.
Type the following command and press Enter to execute it:

ldifde -f UserContainer.txt d "cn=users,dc=companyabc,dc=com"

This command creates a file containing all the attributes and values of the User container and all the objects within it.

5.
To open the output file to see what the LDIF format looks like, in the command-prompt window, type the filename to open it in Notepad.

You also can use these tools to perform directory imports if necessary. One limitation is that you cannot set the initial password using these tools.

Connecting to Flat File Data Sources

You can connect to flat files with pure VBScript commands. Using the File System Object model, you can complete file read and write operations.

Files can be opened for reading, writing, or appending to an existing file. When files are opened for reading, the data can be read one character at a time, line by line, or the entire file can be opened and loaded into memory. As an example, the following script will read the boot.ini file of a Windows Server 2003 server; it will then read one line at a time and output that information to the console in a message box until the file reaches the "end of file marker" triggering a final message to be sent.

Dim FSO, TheFile, Line
Set FSO = CreateObject("Scripting.FileSystemObject")
Set TheFile = FSO.OpenTextFile("C:\boot.ini", 1)
Do While NOT TheFile.AtEndOfStream
Line = TheFile.ReadLine
MsgBox Line
Loop
MsgBox "The end of the file has been reached."

This script creates a File System Object based on the boot.ini file. The script reads a single line and outputs it to the screen for each line in the file until the file reaches the end. At that point, a confirmation pop-up window states that the end of file has been reached.


Searching Active Directory

Sometimes searching Active Directory can prove to be the most efficient way to create a list of users, groups, or computers in the organization for the purposes of administration or inventory. You can search to find a particular attribute value of an object attribute, or you can search to check whether an object already exists before attempting to create a new one. For example, if you're running a script to create several hundred users, you could use a search script to find existing user objects that already have the same logon name. A value could be returned to reference that conflicting account, and the script can run for the remaining users. As an alternative, the error generated when a user already exists could be used as a reference, but you would have to know the exact error code that would result. You can use ADSI to search Active Directory, but for faster searches within a script, you should use the ActiveX Data Object (ADO) interface and object model.

ActiveX Data Objects

ADO is a programming object model that is used to access databases and/or directories from within a script or a Web page. ADO can be used not only to access existing databases records, but also to add new records, delete records, or modify existing records. When you use ADO to search databases or directories, you should format the queries using common structured SQL queries. The particular databases being accessed will determine whether the query needs to be modified from standard SQL code.

Creating a Search Using ADO

ADO can be used to search an entire Active Directory domain or just a particular container object. As mentioned previously, the domain's or container's ADSPath attribute will be used as the root of the search. You will need to specify the data that should be returned and also use a filter for the search. You can use ADO for a variety of directory and database operations and should research ADO documentation. For connecting to Active Directory, use the following commands to call ADO and prepare to make a connection. After you define these connection settings, you can open a connection to the directory and search string and can pass requested directory information to the directory. To create a connection to Active Directory, using the Companyabc.com domain as an example and returning a list of all the computers in the domain, create a script called findpc.vbs using the following code:

Dim DomainDN, ComputerName
DomainDN = "dc=companyabc,dc=com"
Set oConnection = CreateObject("ADODB.Connection")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "DS Query"
Set oCommand = CreateObject("ADODB.Command")
Set oCommand.ActiveConnection = oConnection
oCommand.CommandText = "Select cn from 'LDAP://" + DomainDN + "' where objectClass='computer'"
Set rsComputers = oCommand.Execute
Wscript.echo "This is the list of all the computers in the domain."
Do While NOT rsComputers.EOF
ComputerName = rsComputers.Fields("cn")
Wscript.echo ComputerName
rsComputers.MoveNext
Loop

By changing only the domainDN variable value to the distinguished name attribute value of the domain, domain container, or organizational unit, you can modify this script for any Active Directory domain.

The preceding code is a basic ADO search that you can easily modify by changing only the CommandText value. This value defines the container object to bind to, what the search criteria are, and what attribute values of the objects that meet the search criteria should be returned to a variable or, in this case, the console.

Searching Using the Active Directory Users and Computers MMC Snap-in

When it comes to creating a search string, many administrators can become frustrated with the formatting of the query. To help simplify this task, the new and improved Active Directory Users and Computers MMC snap-in for Windows Server 2003 has a new applet called Saved Queries. This tool can be used to create a query for searches that administrators perform on a regular basis or for administrative tasks such as finding every user with a particular City value. To use this function, refer to the help pages associated with the Active Directory Users and Computers snap-in.

Note

The query text that is generated using the Saved Queries applet is not directly portable into an ADO search string. To properly format a search string for ADO, refer to the ADO documentation.


Windows Server 2003 Scripting

When it comes to scripting tasks for the Windows Server 2003 system, you can find the server objects in Active Directory using ADSI or ADO. To actually connect to the server to make changes or record information, you should use Windows Management Instrumentation. WMI can be used to access the operating system to collect performance statistics. ADSI can be used to create, query, or modify Active Directory objects through an LDAP or global catalog (GC) connection. Likewise, command-line tools can be used to perform a variety of tasks, from remotely rebooting a server to mapping network drives and printers.

Introducing Windows Management Instrumentation

Windows Server 2003 systems can be managed using the interfaces and object models available with Windows Management Instrumentation. WMI is Microsoft's implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative, aimed at providing better management and improved remote monitoring of server and network devices in the enterprise. WMI can be used to access and manipulate server files and file security and handle server configurations such as creating file shares or installing printers and managing services. WMI can also be used to manage applications such as terminal services through specific WMI providers.

Creating a Simple WMI Script

As in the previous scripts outlined to manage users, before you can access or manipulate objects, you must know how to connect, what properties can be managed, and how they can be managed. In other words, you need to become familiar with the WMI interface and the object model for servers or workstations. To create a simple WMI script to connect to a specific server and list each of the local volume drive letter assignments and total volume capacity, follow these steps:

1.
Log on to a workstation or server with an account that has administrative rights on the server you want to query.

2.
Choose Start, Run.

3.
Type notepad.exe and click OK. Enter the following code in the Notepad window:

[View full width]
Set oWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}! \\dc1.companyabc
  .com\root\cimv2")
Set colDisks = oWMIService.ExecQuery ("Select * from Win32_LogicalDisk")
For Each oDisk In colDisks
If oDisk.DriveType = 3 Then
Wscript.echo oDisk.Name & vbTab & CStr(Round(oDisk.Size/1048576))
End If
Next

4.
Using the code from step 3, change the reference from dc1.companyabc.com to the fully qualified domain name of your server or workstation.

5.
Save the file as diskinfo.vbs in the c:\Scripts directory and close Notepad.

6.
Choose Start, Run.

7.
Type cmd.exe and click OK to open a command prompt.

8.
At the command prompt, type c:\scripts\diskinfo.vbs and press Enter. The disk drive letters should then be listed along with their volume capacity.

You can extend this script to also list free space by changing the oDisk.Size reference to oDisk.FreeSpace. Change this code in your script to see the difference.

Administrators also usually need to remotely stop and restart a service on a server. Although you can perform this task using a graphical user interface, using a WMI script provides the flexibility to change the script to manage a different server or many servers in an OU or domain. As an example, the following script will connect to the server dc1.companyabc.com and stop and start the World Wide Web Publishing service:

[View full width]
Set oService = GetObject("winmgmts:{impersonationLevel=impersonate}! \\dc1\root\CIMV2
  :Win32_Service.Name=" + Chr(34) + "W3SVC" + Chr(34))
If oService.Started Then
oService.StopService
Wscript.echo "the service has been stopped"
Wscript.sleep 5000
oService.StartService
Wscript.echo "The service has been restarted."
Else Wscript.echo "The service is not currently running and will not be started."
End If
Set oService = Nothing

Using the preceding code, you should change the reference from dc1.companyabc.com to the fully qualified domain name of your server; this will work only if the server already has IIS Web services installed. Because this service may take a few seconds to stop, the wscript.sleep command was added to pause the script for 5 seconds, or 5,000 milliseconds. The better way to let the service finish before restarting is to monitor the status of the service (Starting, Running, Stopping, Stopped, and so on). Another significant improvement would be to enumerate dependent services and restart them along with this service.

To change this script to manage a different service, replace W3SVC with the desired service name. To locate the correct service name to use with this script, open the Services applet, open the properties of the desired service, and locate the service name referenced at the top of the General tab. Use the service name, not the display name.


Leveraging Sample Scripts

In the following sections, we've included a few sample scripts that leverage and combine some of the interfaces and object models referenced throughout this chapter. These scripts are ready to run if you type them in as shown. However, these scripts do query and return values from the entire domain, so you should test these scripts in an isolated lab environment or scale down and modify the scripts as necessary.

Finding Orphaned Group Policies

The following script searches for Group Policies that are not linked to any specific container in a domain or are otherwise orphaned. It can be saved as a .vbs script (for example, OrphanedGP.vbs).

[View full width]
Dim GP(10000,2)

Set FSO = CreateObject("Scripting.FileSystemObject")
Set oGPList = FSO.OpenTextFile("OrphanGP.txt",2,True)

Set RootDSE = GetObject("LDAP://RootDSE")
DomainNC = RootDSE.Get("RootDomainNamingContext")

Set con = CreateObject("ADODB.Connection")
con.Provider = "ADsDSOObject"
con.Open "DS Query"
Set command = CreateObject("ADODB.Command")
Set command.ActiveConnection = con
Command.Properties("searchscope") = 2

wscript.echo "Retrieving list of all containers in the domain..."
command.CommandText = "select GPLink,Name,ADsPath from 'LDAP://" & DomainNC & "'
where objectclass='organizationalunit' or objectclass='container' or
objectclass='site' or objectclass='domain'"
Set rs = Command.Execute

wscript.echo "Creating list of all assigned Group Policy objects..."
i = 0
Do While NOT rs.EOF
    tempGPLink = rs.Fields("GPLink")
    GPList = ParseGPLink(tempGPLink)

    'GPList returns a Tab-separated string
    'Split() function parses the string and returns an array
    GPArray = Split(GPList,vbTab)
    For j = 0 To UBound(GPArray)
        GP(i,0) = "{" & Split(GPList,vbTab)(j) & "}"
        GP(i,1) = rs.Fields("ADsPath")
        i = i + 1
    Next
    rs.MoveNext
Loop
Ngp = i

wscript.echo "Retrieving list of all Group Policy objects..."
command.CommandText = "select cn,DisplayName,name from 'LDAP://" & DomainNC & "
' where objectclass='GroupPolicyContainer'"
Set rs = Command.Execute

wscript.echo "Detecting orphan Group Policy objects..."
Do While NOT rs.EOF
    GPName = rs.Fields("DisplayName")
    If TypeName(GPName) = "String" Then
        OUFound = False
        'Searching for a GP in the array of all assigned GPs created
in the previous step
        'It would be more efficient to use a Dictionary object instead of array,
        'but for arrays of this size the performance difference
is not significant
       For i = 0 to Ngp - 1
           If rs.Fields("name") = GP(i,0) Then
               OUFound = True
           End If
       Next
       If NOT OUFound Then
           wscript.echo GPName
           oGPList.WriteLine GPName & vbTab & rs.Fields("cn")
       End If
   End If
   rs.MoveNext
Loop

Function ParseGPLink(GPLink)
    'GPLink attribute can contain links to multiple group policies:
    '"[LDAP://CN={217E2467-F743-4300-812C-2F87FBF9AFD3},CN=Policies,CN=System, DC=mydomain
  ,DC=com;2][LDAP://CN={3CEF68F7-0201-407F-87E9-DF6CF8255E2D},
CN=Policies,CN=System,mydomain=domain-name,DC=com;0]"
    'This function reformats the value to make it a Tab-separated string:
    '"217E2467-F743-4300-812C-2F87FBF9AFD3
    3CEF68F7-0201-407F-87E9-DF6CF8255E2D"
    'Strings like that are much easier to work with
    Dim j, TempArray
    ParseGPLink = ""

    If TypeName(GPLink) = "String" AND Trim(GPLink) <> "" Then
        TempArray = Split(GPLink,"{")
        For j = 1 To UBound(TempArray)
            ParseGPLink = ParseGPLink & Left(TempArray(j),
InStr(TempArray(j),"}") - 1) & vbTab
        Next
        ParseGPLink = Left(ParseGPLink, Len(ParseGPLink)-1)
    End If
End Function

Scanning for Installed Software Components

Many times administrators need to quickly and easily scan a computer or group of computers to determine whether or not a specific software component has been installed. Although the following script scans for Macromedia Flash Player, it can also be used to scan for computers with a specific update installed. For instance, you can change the Query variable:

Query = "SELECT * FROM Win32_QuickFixEngineering WHERE HotFixID='Q329115'"

(where Q329115 is the update you are looking for).

Set RootDSE = GetObject("LDAP://RootDSE")
DomainNC = RootDSE.Get("RootDomainNamingContext")

Set ws = CreateObject("WScript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")

Set oSoftwareScan = FSO.OpenTextFile("SoftwareScan.csv",2,True)

Set con = CreateObject("ADODB.Connection")
con.Provider = "ADsDSOObject"
con.Open "DS Query"
Set command = CreateObject("ADODB.Command")
Set command.ActiveConnection = con
Command.Properties("Sort on") = "cn"
Command.Properties("searchscope") = 2

command.CommandText = "select cn,ADsPath from 'LDAP://" & DomainNC & "
' where objectclass='computer' and operatingsystem='Windows 2000 Professional'"
Set rs = command.Execute

Query = "SELECT * FROM Win32_Product WHERE Name='Macromedia Flash Player'"

Do While NOT rs.EOF
    ComputerName = rs.Fields("cn")
    Version = ""
    If Online(ComputerName) Then
        Set WMIRef = GetObject("winmgmts:{impersonationLevel=impersonate}!\\"
 & ComputerName)
            Set colProducts = WMIRef.ExecQuery(Query)
            Status = "Not installed"
            For Each oProduct In colProducts
                Version = oProduct.Version
                Status = "Installed"
            Next
       Else
            Status = "Offline"
       End If

       wscript.echo ComputerName & vbTab & Status & vbTab & Version
       oSoftwareScan.WriteLine ComputerName & "," & Status & "," & Version

       ComputerName = Null
       Status = Null
       rs.MoveNext
   Loop
   oSoftwareScan.Close

   Function Online(HostName)
       'Shell ping command is used here to determine whether the computer is online
       'It's done this way only for the purpose of compatibility with Windows 2000
       'Win32_PingStatus class is available for Windows Server 2003
    and should be used instead
       Dim ReturnCode, Results, Line
       Online = False
       Returncode = ws.Run("%comspec% /c ping " & HostName & ".domain-name.com -n 1
   -w 500 > ping.tmp",0,"True")
       set Results = fso.OpenTextFile("ping.tmp",1,False)
       Do While NOT Results.AtEndOfStream
           Line = Results.ReadLine
           If (InStr(Line, "Reply from") > 0) AND (InStr(Line, "unreachable") = 0)
     Then
               Online = True
           End If
       Loop

    Results.Close
    Set Results = Nothing
    FSO.DeleteFile "ping.tmp"
End Function

Checking Local Group Membership

The following script determines local group membership. The script first finds the computer object in Active Directory and then it analyzes group membership of that object by finding the group whose name includes the "-Computers" substring. For example, if a group named "Marketing-Computers" exists, it indicates that the computer belongs to the Marketing department. The script then enumerates members of the local Administrators group to determine whether the Marketing-Admins group is already a member of the local Administrators group. If it isn't, then the script adds it in there.

The script also contains code to write Application log events if the group is added and whether or not critical errors occurred. Another important piece of this script is the section of code containing the Option Explicit and declared variables. This is a good habit to practice with all scripts even though all the examples in this chapter do not contain them. Option Explicit enforces variable declaration.

Option Explicit
Dim RootDSE, DomainNC, ws, WNetwork, CompName, Department
Dim AdminGroup, AdminGroupFound, oUser, oGroup

on error resume next
Const EventERROR = 1, EventWARNING = 2, EventINFORMATION = 4

Set RootDSE = GetObject("LDAP://RootDSE")
DomainNC = RootDSE.Get("RootDomainNamingContext")

Set ws = CreateObject("WScript.Shell")
Set WNetwork = Wscript.CreateObject("WScript.Network")
CompName = WNetwork.ComputerName

'Determining department where the computer account belongs
Department = GetDepartment(CompName)

If Department <> "" Then
    AdminGroup = Department & "-Admins"
Else
    AdminGroup = "IT-Admins"            'if the computer is not a member of any
 XXX-Computers group, then it should be managed by IT
End If

'Enumerating members of the local Administrators group
Set oGroup = GetObject("WinNT://" & CompName & "/Administrators,group")
AdminGroupFound = False
For Each oUser in oGroup.Members
    If oUser.Name = AdminGroup Then
        AdminGroupFound = True
    End If
Next
If Err.Number <> 0 Then
    'creating an event in the Application log and exiting the script
    ws.Logevent EventERROR, "Error occurred while enumerating members of the
 local Administrators group"
    wscript.quit
End If

'Adding Admin group only if it wasn't found in the local Administrators group
If NOT AdminGroupFound Then
    oGroup.Add "WinNT://" & AdminGroup & ",group"
    If Err.Number <> 0 Then
        ws.Logevent EventERROR, "Error occurred while adding group "
 & AdminGroup & " into the local Administrators group"
    Else
        ws.Logevent EventINFORMATION, "Successully added group "
 & AdminGroup & " into the local Administrators group"
    End If
End If

Set oGroup = Nothing
Set ws = Nothing
Set WNetwork = Nothing

Function GetDepartment(ComputerName)
    Dim oConnection, oCommand, rs, MemberOf, oGroup, oComputer, i
    Set oConnection = CreateObject("ADODB.Connection")
    oConnection.Provider = "ADsDSOObject"
    oConnection.Open "DS Query"
    Set oCommand = CreateObject("ADODB.Command")
    Set oCommand.ActiveConnection = oConnection
    oCommand.Properties("searchscope") = 2

    oCommand.CommandText = "Select ADsPath,cn From 'LDAP://" & DomainNC & "
' Where name='" + ComputerName + "' and objectclass='computer'"

    Set rs = oCommand.Execute

    GetDepartment = ""
    If NOT rs.EOF Then
        Set oComputer = GetObject(rs.Fields("ADsPath"))

        MemberOf = oComputer.GetEx("memberOf")

        If Err.Number <> 0 Then
'MemberOf attribute is not populated (the object is not a member of any group)
            Err.Clear
            Exit Function
        End If

        If TypeName(MemberOf) = "String" Then
'MemberOf attribute is single-valued (the object is a member of a single group)
            Set oGroup = GetObject("LDAP://" & MemberOf)
            If Instr(oGroup.cn,"-Computers") > 0 Then
                GetDepartment = Left(oGroup.cn, Len(oGroup.cn) - 10)
            End If
        Else
'MemberOf attribute is multi-valued (the object is a member of multiple groups)
            For i = 0 To UBound(MemberOf)
                Set oGroup = GetObject("LDAP://" & MemberOf(i))
                If Instr(oGroup.cn,"-Computers") > 0 Then
                    GetDepartment = Left(oGroup.cn, Len(oGroup.cn) - 10)
                    Exit For
                End If
                Set oGroup = Nothing
            Next
        End If
    End If
End Function

Locating Domain Printers

The following script creates a list of all printers in Active Directory and outputs the information gathered in a text file called AllPrinters.csv. Here is some other pertinent information:

  • Local printers (connected to Win9x and other client OS computers) are skipped.

  • The script uses LDAP query to create a recordset of all servers in the domain.

  • Another query is used to find all printers for every server.

  • The script uses WMI to bind to Win32_Printer objects.

The full script is as follows:

Option Explicit
Dim RootDSE, DomainDN, FSO, oFullLog, oConnection, oCommand, rsServers,
rsPrinters
Dim Sep, PrintServer, oPrinter

Set RootDSE = GetObject("LDAP://RootDSE")
DomainDN = RootDSE.Get("RootDomainNamingContext")

Set FSO = CreateObject("Scripting.FileSystemObject")
Set oFullLog = FSO.OpenTextFile("AllPrinters.csv", 2, True)

Set oConnection = CreateObject("ADODB.Connection")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "DS Query"
Set oCommand = CreateObject("ADODB.Command")
Set oCommand.ActiveConnection = oConnection
oCommand.Properties("searchscope") = 2
oCommand.Properties("Sort on") = "cn"

oCommand.CommandText = "Select cn,ADsPath from 'LDAP://" & DomainDN &
"' Where objectClass='computer' and OperatingSystem=
'Windows 2000 Server' OR OperatingSystem='Windows Server 2003'"
Set rsServers = oCommand.Execute
Sep = Chr(34) & "," & Chr(34)

On Error Resume Next

Do While NOT rsServers.EOF
    PrintServer = False
    oCommand.CommandText = "Select PrinterName,cn from '" &
rsServers.Fields("ADsPath") & "' where objectClass='printQueue'"
    Set rsPrinters = oCommand.Execute

    Do While NOT rsPrinters.EOF
        If NOT PrintServer Then
            Wscript.echo rsServers.Fields("cn")
            PrintServer = True
        End If

        Set oPrinter = GetObject("winmgmts:{impersonationLevel=impersonate}!
\\" & rsServers.Fields("cn") & "\root\cimv2:Win32_Printer.DeviceID=
" & Chr(34) & rsPrinters.Fields("PrinterName") & Chr(34))

        Wscript.echo vbTab & rsPrinters.Fields("PrinterName") & vbTab &
txtPrinterStatus(oPrinter.PrinterStatus)

        oFullLog.WriteLine Chr(34) & rsServers.Fields("cn") & Sep &
rsPrinters.Fields("PrinterName") & Sep & oPrinter.DriverName &
Sep & oPrinter.Location & Sep &
oPrinter.Description & Sep & txtPrinterStatus(oPrinter.PrinterStatus)
& Chr(34)

        Set oPrinter = Nothing
        rsPrinters.MoveNext
    Loop

    Set rsPrinters = Nothing
    rsServers.MoveNext
Loop

Set rsServers = Nothing
Set oCommand = Nothing
Set oConnection = Nothing

oFullLog.Close
Set oFullLog = Nothing
Set FSO = Nothing
Set RootDSE = Nothing
Function txtPrinterStatus(PrinterStatus)
    Select Case PrinterStatus
        Case 1 : txtPrinterStatus = "Other"
        Case 2 : txtPrinterStatus = "Unknown"
        Case 3 : txtPrinterStatus = "Idle"
        Case 4 : txtPrinterStatus = "Printing"
        Case 5 : txtPrinterStatus = "Warmup"
        Case Else txtPrinterStatus = "Unknown Status"
    End Select
End Function

Creating Users from Data in a CSV File

The following script creates users in the Users container in Active Directory. The script reads data for user creation in a Users.csv file. The file header defines attributes that will be populated. Only two attributes are mandatory: SamAccountName (also called the logon name) and CN (the canonical name). All other attributes are optional, including the password. The sample data used for this script would appear as follows if the Users.csv file were opened in Notepad:

SamAccountName,CN,GivenName,SN,Initials,Password
jsmith,John Smith,John,Smith,T,mysecretpassword
brobinson,Bob Robinson,Bob,Robinson,K,mysecretpassword

Attribute names should be specified exactly as they are defined in the Active Directory schema. Probably the best tool to determine which attributes should be specified is the ADSI Edit tool. If the script fails to create a user, an error message appears. Usually, errors are caused by an invalid attribute value or by the fact that a user with the same SamAccountName already exists in the domain. If at least one of the fields is specified incorrectly, an error will be reported for all users. Finally, all users are enabled after the creation.

The full script is as follows:

Option Explicit
Dim RootDSE, DomainDN, oContainer, FSO, oUserList
Dim Line, Header, SamaccountnameIndex, CnIndex, PasswordIndex,
 AttributeValue, oUser, i

Set RootDSE = GetObject("LDAP://RootDSE")
DomainDN = RootDSE.Get("RootDomainNamingContext")

Set oContainer = GetObject("LDAP://CN=Users," + DomainDN)

Set FSO = CreateObject("Scripting.FileSystemObject")
Set oUserList = FSO.OpenTextFile("Users.csv",1,False)

on error resume next

Line = LCase(oUserList.ReadLine)
Header = Split(Line,",")

SamaccountnameIndex = -1
CnIndex = -1
PasswordIndex = -1
For i = LBound(Header) To UBound(Header)
    If Header(i) = "samaccountname" Then
        SamaccountnameIndex = i
    ElseIf Header(i) = "cn" Then
        CnIndex = i
    ElseIf Header(i) = "password" Then

        PasswordIndex = i
    End If
Next
If SamaccountnameIndex = -1 OR CnIndex = -1 Then
    Wscript.echo "Incorrect header. One of the mandatory fields is missing."
    wscript.quit
End If

Do While NOT oUserList.AtEndOfStream
    Line = oUserList.ReadLine
    AttributeValue = Split(Line,",")

    Wscript.echo AttributeValue(CnIndex)
    set oUser = oContainer.Create("user","cn="& AttributeValue(CnIndex))
    oUser.samAccountName = AttributeValue(SamAccountNameIndex)
    oUser.SetInfo

    If Err.Number <> 0 Then
        Wscript.echo vbTab + "Error occurred while creating the user"
    Else
        Wscript.echo vbTab + "User created successfully"

        For i = LBound(Header) To UBound(Header)
            If i <> CnIndex AND i <> SamaccountnameIndex AND i <> _
PasswordIndex Then
               oUser.Put Header(i),AttributeValue(i)
           ElseIf i = PasswordIndex Then
               oUser.SetPassword AttributeValue(i)
           End If
       Next
       oUser.AccountDisabled = False
       oUser.SetInfo

       If Err.Number <> 0 Then
           Wscript.echo vbTab + "Error occurred while setting user properties"
           Err.Clear
       Else
           Wscript.echo vbTab + "User properties were set successfully"
       End If
   End If

   Set oUser = Nothing
   Line = Null

    AttributeValue = Null
Loop

oUserList.Close
Set oUserList = Nothing
Set FSO = Nothing
Set RootDSE = Nothing

Checking Domain Servers for Volume Free Space

The following script expands on the sample WMI script outlined earlier in this chapter. The script scans all Windows 2000 and Windows Server 2003 servers in a domain and reports free space and total capacity (in megabytes and percents) on every logical drive. The script uses LDAP query to create a recordset of all servers in the domain. It also uses Windows Management Instrumentation to demonstrate usage of this technology, but the same information can also be collected using the File System Object model.

Option Explicit
Dim oRootDSE, DomainDN, FSO, oLogFile, oConnection, oCommand, rsServers
Dim ComputerName, oWMIService, colDisks, oDisk
Dim PercentFree

Set oRootDSE = GetObject("LDAP://RootDSE")
DomainDN = oRootDSE.Get("RootDomainNamingContext")

Set FSO = CreateObject("Scripting.FileSystemObject")
Set oLogFile = FSO.OpenTextFile("FreeSpace.csv",2,True)

Set oConnection = CreateObject("ADODB.Connection")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "DS Query"
Set oCommand = CreateObject("ADODB.Command")
Set oCommand.ActiveConnection = oConnection
oCommand.Properties("searchscope") = 2

oCommand.CommandText = "Select ADsPath,cn From 'LDAP://" & DomainDN & _
 "' Where objectClass='computer' and OperatingSystem='Windows 2000 Server'
 OR OperatingSystem='Windows Server 2003'"
Set rsServers = oCommand.Execute

On Error Resume Next

Do While NOT rsServers.EOF

    ComputerName = rsServers.fields("cn").value
    Wscript.echo ComputerName

    Set oWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!
\\" & ComputerName & "\root\cimv2")
    Set colDisks = oWMIService.ExecQuery ("Select * from Win32_LogicalDisk")

    For Each oDisk In colDisks
        If oDisk.DriveType = 3 Then        'Local Hard Drive
            PercentFree = Round(oDisk.FreeSpace/oDisk.Size*100)
            Wscript.echo oDisk.Name & vbTab & _
CStr(Round(oDisk.FreeSpace/1048576)) & "/" & _
CStr(Round(oDisk.Size/1048576)) & vbTab & CStr(PercentFree) & "%"
           oLogFile.WriteLine ComputerName & "," & oDisk.Name &
"," & CStr(Round(oDisk.FreeSpace/1048576)) & "," & _
CStr(Round(oDisk.Size/1048576)) & "," & CStr(PercentFree)
       End If
   Next

   If Err.Number <> 0 Then
       Wscript.echo "Error while collecting information from " & ComputerName
       Err.Clear
   End If

   Set oWMIService = Nothing
   Set colDisks = Nothing
   rsServers.MoveNext
Loop

Set rsServers = Nothing
Set oCommand = Nothing
Set oConnection = Nothing
oLogFile.Close
Set oLogFile = Nothing
Set FSO = Nothing


Summary

Scripting for Windows Server 2003 systems and Active Directory can simplify many IT-related administrative tasks. Leveraging the scripting languages provided by Microsoft and the many different programming interfaces and object models, there is almost no task that cannot be scripted if the device or object is referenced correctly. This chapter just scratched the surface on scripting possibilities and, we hope, has sparked ideas on how scripting can simplify managing an IT environment.


Best Practices

  • If a command such as Wscript.echo is used several times in a script, be sure to run the script using Cscript.

  • Use Active Directory Users and Computers and ADSI Edit to discover the directory names of object attributes and to find out what possible attributes an object can contain.

  • Populate attributes using variables to save time when writing scripts that will create several user accounts.

  • Use a script to create users and also mail-enable those users.

  • Use Ldifde.exe and Csvde.exe for creating directory objects using clean formatted data presented in LDIF or CSV format.

  • Use WMI to access and manipulate server files and file security.


Chapter 24. Documenting a Windows Server 2003 Environment

In This Chapter

  • Benefits of Documentation

  • Design and Planning Documentation

  • Migration Documentation

  • Active Directory Infrastructure

  • Network Infrastructure

  • Administration and Maintenance Documentation

  • Disaster Recovery Documentation

  • Performance Documentation

  • Security Documentation

  • Training Documentation

Many of the previous chapters discussed the importance of documentation in a Windows Server 2003 environment. This chapter looks at the many different types of documentation and discusses the benefitssome of which are obvious, some not.

There are several main types of documentation, including the following:

  • Historical/planning (who made which decision)

  • Support and maintenance (to assist with maintaining the hardware and software on the network)

  • Policy (service-level agreements)

  • Training (for end users or administrators)

It is also critical that any documentation produced be reviewed by other stakeholders in the organization to make sure that it meets their needs as well, and to simply get input from other sources. For technical procedures, the document also must be tested and "walked through." With a review process of this sort, the document will be more useful and more accurate. For example, a server build document that has gone through this process (that is, reviewed by the IT manager and network administrator) is more likely to be complete and useful in case the server in question needs to be rebuilt in an emergency.

Documentation that is not historical and that is intended to be used for supporting the network environment or to educate on company policies should be reviewed periodically to make sure that it is still accurate and reflects the current corporate policies and processes.

The discipline of creating effective documentation that satisfies the requirements of the appropriate support personnel as well as management is also an asset to the company and can have dramatic effects. The material in this chapter gives a sense of the range of different documents that can have value to an organization and should help in the process of deciding which ones are critical in the organization.


Benefits of Documentation

Some of the benefits of documentation are immediate and tangible, whereas others can be harder to pin down. The process of putting the information down on paper encourages a level of analysis and review of the topic at hand that helps to clarify the goals and contents of the document. This process should also encourage teamwork and collaboration within the organization, as well as interdepartmental exchange of ideas.

For example, an Exchange Server maintenance document written by the Exchange administrator might be reviewed by the marketing manager who is concerned about the company's ability to send out emails to the existing and potential client base. The CIO should review the document as well to make sure that the maintenance process meets her concerns, such as meeting an aggressive service-level agreement (SLA).

Consequently, documentation that has specific goals, is well organized and complete, and goes through a review or approval process should contribute to the overall professionalism of the organization and its knowledge base. The following sections examine some of the other benefits of professional documentation in the Windows Server 2003 environment.

Knowledge Management

Quite simply, the right documentation allows an organization to better organize and manage its data and intellectual property. Rather than having the company's policies and procedures in a dozen places, such as individual files for each department or worst of all, in the minds of many individuals, consolidating this information into logical groupings can be beneficial.

A design document that details the decisions made pertaining to a Windows Server 2003 migration can consolidate and summarize the key discussions and decisions, as well as budgetary concerns, timing issues, and the like. And there will be one document to turn to if questions emerge at a later date.

Similarly, if a service-level agreement is created and posted where it can be accessed by any interested parties, it should be very clear what the network users can expect from the Windows Server 2003 infrastructure in terms of uptime or prescheduled downtimes.

A document that describes the specific configuration details of a certain server or type of server might prove very valuable to a manager in another company office when making a purchasing decision. The documents also must be readily available so that they can be found when needed, especially in the case of disaster recovery documents. Also, it's handy to have them available in a number of formats, such as hard copy, in the appropriate place on the network and even via an intranet.

Tip

Place documentation in various locations where it is easily accessible for authorized users, such as on the intranet, in SharePoint Portal Server, in Windows SharePoint Services, in a public folder, or in hard-copy format.

By simply having these documents available and centralizing them, an organization can more easily determine the effects of changes to the environment and track those changes. Part of the knowledge-management process needs to be change management so that, while the information is available to everyone, only authorized individuals can make changes to the documents.

Financial Benefits

Proper Windows Server 2003 documentation can be time consuming and adds to infrastructure and project costs. It is often difficult to justify the expense of project documentation. However, when looking at documents, such as in maintenance or disaster recovery scenarios, it is easy to determine that creating this documentation makes financial sense. For example, in an organization where downtime can cost thousands of dollars per minute, the return on investment (ROI) on disaster recovery and maintenance documentation is easy to calculate. Likewise, in a company that is growing rapidly and adding staff and new servers on a regular basis, tested documentation on server builds and administration training can also have immediate and visible benefits.

Well-thought-out and professional design and planning documentation should help the organization avoid costly mistakes in the implementation or migration process, such as buying too many server licenses or purchasing too many servers.

Baselining with Document Comparisons

Baselining is a process of recording the state of a Windows Server 2003 system so that any changes in its performance can be identified at a later date. Baselining also pertains to the overall network performance, including WAN links, but in those cases it may require special software and tools (such as sniffers) to record the information.

A Windows Server 2003 system baseline document records the state of the server after it is implemented in a production environment and can include statistics such as memory utilization, paging, disk subsystem throughput, and more. This information then allows the administrator or appropriate IT resource to determine how the system is performing in comparison to initial operation.

Using Documentation for Troubleshooting Purposes

Troubleshooting documentation is helpful both in terms of the processes that the company recommends for resolving technical issues, as well as documenting the results of actual troubleshooting challenges. Often, companies have database and trouble-ticket processes in place to record the time a request was made for assistance, the process followed, and the results. This information should then be available to the appropriate support staff so they know the appropriate resolution if the problem comes up again.

Organizations may also choose to document troubleshooting methodologies to use as training aids and also to ensure that specific steps are taken as a standard practice for quality of service to the user community.


Design and Planning Documentation

Chapter 2, "Planning, Prototyping, Migrating, and Deploying Windows Server 2003 Best Practices," provides a detailed look at the type of documentation needed in the design and planning process. This documentation is extremely important when an organization engages in a new project in that it provides both a historical record of what and how the decisions were made and makes sure that the stakeholders are in agreement.

Documenting the Design

The first step in the implementation of Windows Server 2003 environment is the development and approval of a design. Documenting this design contributes to the success of the project. The design document records the decisions made during the design process and provides a reference for testing, implementation, and support. The key components to a design document include the following:

  • The goals and objectives of the project

  • The background or what led up to the design

  • The approach that will be used to implement the solution

  • The details of the end state of the project

Goals and objectives can be surprisingly hard to pin down. They need to be detailed and concrete enough to define the results that you want while staying at a high level. For instance, "reduce downtime" is too vague to be considered a functional goal, whereas "implement server clustering with Windows Server 2003 Enterprise Edition to reduce downtime to less than five minutes in the case of single server failure" is much more specific.

Including the background of meetings and brainstorming sessions that led up to the decisions for the end state of the project provides the groundwork for the detailed designs provided later in the document. For example, a decision may have been made "because the CEO wants it that way," which affects the post-migration environment. Other decisions may have come about after many hours of debates over the particulars and required technical research to come up with the "right" answer. Recording this level of information can be extremely useful in the future if performance issues are encountered or additional changes to the network are being considered.

The description of the end state to be implemented can be very high level or can drill down to more specific configurations of each server, depending on the document's audience. However, it is recommended that the design document not include step-by-step procedures or other details of how the process will be accomplished. This level of detail is better handled, in most cases, in dedicated configuration or training documents as discussed later in this chapter.


Migration Documentation

Migration documentation can be created at the same time or shortly after the design documentation to provide a roadmap of the Windows Server 2003 migration. It can also be created after the testing phase is completed, depending on time and resources available. If produced shortly after the design document, this document may need updating after the prototype or testing phase to more accurately reflect the migration process.

Note

The results of testing the design in a prototype or pilot might alter the actual migration steps and procedures. In this case, the migration plan document should be modified to take these changes into account.

The following is a table of contents for a Windows Server 2003 migration plan:

Windows Server 2003 Migration Plan
Goals and Objectives
Approach
Roles
Process
    Phase I  Design and Planning
    Phase II  Prototype
    Phase III  Pilot
    Phase IV  Implementation
    Phase V  Support
Migration Process
    Active Directory Preparation
    Windows NT
    Windows 2000
Summary of Migration Resources
Project Scheduling
Windows Server 2003 Training
Administration and Maintenance

Project Plans

A project plan is essential for more complex migrations and can be useful for managing smaller projects, even single server migrations. Tasks should be laid out in the order in which they will occur and be roughly half-day durations or more, because a project plan that tries to track a project hour by hour can be overwhelmingly hard to keep up to date.

Tools such as Microsoft Project facilitate the creation of project plans (see Figure 24.1) and enable the assignment of one or more resources per task and the assignment of durations and links to key predecessors. The project plan can also provide an initial estimate of the number of hours required from each resource and the associated costs if outside resources are to be used. "What if" scenarios are easy to create by simply adding resources to more complex tasks or cutting out optional steps to see the effect on the budget.

Figure 24.1. A sample project plan.

[View full size image]

Note that it's a great idea to revisit the original project plan after everything is completed (the baseline) to see how accurate it was. Many organizations fail to take this step and miss the opportunity of learning from the planning process to better prepare for the next time around.

Developing the Test Plan

Thorough testing is critical in the success of any implementation project. A test plan details the resources required for testing (hardware, software, and lab personnel), the tests or procedures to perform, and the purpose of the test or procedure.

It is important to include representatives of every aspect of the network in the development of the test plan. This ensures that all aspects of the Windows Server 2003 environment or project and its impact will be included in the test plan.

Server Migration Procedures

High-level migration procedures should be decided on during a design and planning process and confirmed during a prototype/testing phase. The initial migration document also should focus on the tools that will be used to migrate data, users, and applications, as well as the division of labor for these processes.

A draft of the document can be put together, and when the process is tested again, it can be verified for accuracy. When complete, this information can save you a great deal of time if a number of servers need to be migrated.

Tip

Server migration procedures should be written in such a way so that even less-experienced resources can use the procedures for the actual migrations.

The procedures covered can include the following:

  • Server hardware configuration details

  • Windows Server 2003 version for each server

  • Service pack (SP) and hotfixes to install on each server

  • Services (such as DNS and DHCP) to enable or disable and appropriate settings

  • Applications (such as antivirus and SQL Server) to install and appropriate settings

  • Security settings

  • Steps required to migrate services and data to the new server(s)

  • Steps required to test the new configuration to ensure full functionality

  • Steps required to remove old servers from production

Desktop Migration Procedures

As with the documented server migration process, the desktop migration process should be discussed in the design and planning phase and documented in the migration document. In some migrations to Windows XP, the changes may be minimal, whereas other migrations may require dramatic upgrades. For instance, a desktop machine may qualify for an inplace upgrade to Windows XP, while another may require hardware or a system replacement.

What specifically is documented will vary between organizations; however, the recommended areas to consider documenting are as follows:

  • Hardware inventory

  • Installation method(s) (such as Remote Installation Services, third-party imaging software, and network-based installations)

  • Base installation applications

  • Security configuration

  • Templates being used

  • Language options

  • Accessibility considerations

User Migration Procedures

Users and their related information (username, password, and contact information) in other systems or directories need to be migrated to take advantage of Windows Server 2003. The procedures to migrate the users should be examined during the design and planning phases of the project.

User information may exist in many different places such as an Active Directory (AD) domain, an application, and more. The user information may be inconsistent depending on where it exists and how it is stored. Procedures should be documented for migrating the user information from each different location. For example, if some users will be migrated from another operating system or from multiple forests, separate procedures should be documented for each process.

Another scenario to document is the migration of user profiles and desktops. Although some of this information may be redundant with desktop migration scenarios, it is nonetheless important to capture the procedures for making sure that, when clients log on after the migration, all their settings still exist and they won't have any problems with the applications they use. This is a very important consideration for mobile users. For instance, will mobile users need to come back into the office to have settings changed or migrated? Will these changes be performed the next time they log on?

Checklists

The migration process can often be a long process, based on the amount of data that must be migrated. It is very helpful to develop both high-level and detailed checklists to guide the migration process. High-level checklists determine the status of the migration at any given point in the process. Detailed checklists ensure that all steps are performed in a consistent manner. This is extremely important if the process is being repeated for multiple sites.

The following is an example of a Windows Server 2003 server build checklist:

Task:                                Initials         Notes
Verify BIOS and Firmware Revs
Verify RAID Configuration
Install Windows Server 2003 Enterprise Edition
Configure Windows Server 2003 Enterprise Edition
Install Security Patches
Install Support Tools
Install System Recovery Console
Add Server to Domain
Install Antivirus
Install and Configure Backup Agent
Apply Rights, Templates, and Policies
Set up and Configure Smart UPS

Sign off:                            Date:


Active Directory Infrastructure

Active Directory is one of the core services for a Windows Server 2003 environment. As such, documenting the AD infrastructure is a critical component to the environment. There are many aspects to document as they relate to AD, including, but not limited to, the following:

  • Forest and domain structure such as DNS names, NetBIOS names, mode of operation, and trust relationships

  • Names and placement of domain controllers (DCs) and global catalog (GC) servers

  • Flexible Single Master Operations (FSMO) locations on DCs or GCs

  • Sites, site links, link costs, and site link bridges

  • Organizational unit (OU) topology

  • Special schema entries (such as those made by applications)

  • Security groups and distribution lists

  • AD-integrated DNS information

  • AD security

  • Group Policy Object (GPO) configurations and structure

This information can be extremely useful in day-to-day operations, as well as when you're troubleshooting AD issues such as replication latency or logon problems.


Network Infrastructure

Network configuration documentation is essential when you're designing technologies that may be integrated into the network, when managing network-related services such as DNS, when administering various locations, and when troubleshooting. Network environments usually don't change as much as a server infrastructure. Nonetheless, it's important to keep this information current and accurate through periodic reviews and analysis.

Documenting the WAN Infrastructure

Network configuration documentation also includes WAN infrastructure connectivity. Consider documenting the following:

  • Internet service provider contact names, including technical support contact information

  • Connection type (such as frame relay, ISDN, OC-12)

  • Link speed

  • Committed Information Rate (CIR)

  • End-point configurations, including routers used

Enterprise networks can have many different types of WAN links, each varying in speed and CIR. This documentation is useful not only for understanding the environment, but also for troubleshooting connectivity, replication issues, and more.

Network Device Documentation

Network devices such as firewalls, routers, and switches use a proprietary operating system. Also, depending on the device, the configuration should be documented. Some devices permit configuration dumps to a text file that can be used in the overall documentation, whereas others support Web-based retrieval methods. In worst-case scenarios, administrators must manually document the configurations.

Network device configurations, with possibly the exception of a firewall, rarely change. If a change does occur, it should be documented in a change log and updated in the network infrastructure documentation. This allows administrators to keep accurate records of the environment and also provides a quick documented way to rebuild the proper configurations in case of a failure.

Note

Step-by-step procedures for rebuilding each network device are recommended. This information can minimize downtime and administration.

Configuration (As-Built) Documentation

The configuration document, often referred to as an as-built, details a snapshot configuration of the Windows Server 2003 system as it is built. This document contains essential information required to rebuild a server.

The following is a Windows Server 2003 as-built document template:

Introduction
The purpose of this Windows Server 2003 as-built document is to assist an
experienced network administrator or engineer in restoring the server in the
event of a hardware failure. This document contains screen shots and
configuration settings for the server at the time it was built. If settings
are not implicitly defined in this document, they are assumed to be set to
defaults. It is not intended to be a comprehensive disaster recovery with
step-by-step procedures for rebuilding the server. In order for this document
to remain useful as a recovery aid, it must be updated as configuration
settings change.

System Configuration
    Hardware Summary
    Disk Configuration
        Logical Disk Configuration
    System Summary
    Device Manager
    RAID Configuration
    Windows Server 2003 TCP/IP Configuration
    Network Adapter Local Area Connections
Security Configuration
        Services
        Lockdown Procedures (Checklist)
        Antivirus Configuration
Share List
Applications and Configurations


Administration and Maintenance Documentation

Administration and maintenance documentation can be critical in maintaining a reliable network environment. These documents help an administrator of a particular server or set of servers organize and keep track of the different steps that need to be taken to ensure the health of the systems under his care. They also facilitate the training of new resources and reduce the variables and risks involved in these transitions.

Note that Windows Server 2003 systems, as discussed previously, can serve several different functions on the network, such as file servers, print servers, Web servers, messaging servers, terminal servers, and remote access servers. The necessary maintenance procedures may be slightly different for each one based on its function and importance in the network.

One key component to administration or maintenance documentation is a timeline detailing when certain procedures should be followed. As Chapter 22, "Windows Server 2003 Management and Maintenance Practices," discusses, certain daily, weekly, monthly, and quarterly procedures should be followed. These procedures, such as weekly event log archiving, should be documented to make sure that there are clearly defined procedures and frequency in which they should be performed.

Step-by-Step Procedure Documents

Administration and maintenance documentation contains a significant amount of procedural documentation. These documents can be very helpful for complex processes, or for processes that are not performed on a regular basis. Procedures range from technical processes that outline each step to administrative processes that help clarify roles and responsibilities.

Policies

Although policy documents may not be exciting reading, they can be an administrator's best friend in touchy situations. A well-thought-out, complete, and approved policy document makes it very clear who is responsible for what in specific situations. It's also important to be realistic about which polices need to be documented and what is excessivefor example, document policies concerning when and how the servers can be updated with patches, newer hardware, or software.

Documented Checklists

Administration and maintenance documentation can be extensive, and checklists can be quick reminders for those processes and procedures. Develop comprehensive checklists that will help administrators perform their scheduled and unscheduled tasks. A timeline checklist highlighting the daily, weekly, monthly, and quarterly tasks helps keep the Exchange environment healthy. In addition, these checklists function as excellent auditing tools.

Procedural Documents

Procedural documents can be very helpful for complex processes. They can apply to technical processes and outline each step, or to administrative processes to help clarify roles and responsibilities.

Flowcharts from Microsoft Visio or a similar product are often sufficient for the more administrative processes, such as when testing a new patch to a key software application, approving the addition of a new server to the network, or scheduling network downtime.


Disaster Recovery Documentation

If there is one type of documentation that a network needs, disaster recovery policies and procedures are highly recommended. Every organization should go through the process of contemplating various disaster scenarios. For instance, organizations on the West Coast may be more concerned with earthquakes than those on the East Coast. Each disaster can pose a different threat. Therefore, it's important to determine every possible scenario and begin planning ways to minimize those disasters.

Equally important is analyzing how downtime resulting from a disaster may affect the company (reputation, time, productivity, expenses, loss in profit or revenue) and determine how much should be invested in remedies to avoid or minimize the effects.

A number of different components comprise disaster recovery documentation. Without this documentation, full recovery is difficult at best. The following is a table of contents for the areas to consider when documenting disaster recovery procedures:

Executive Summary or Introduction
Disaster Recovery Scenarios
Disaster Recovery Best Practices
        Planning and Designing for Disaster
Business Continuity and Response
        Business Hours Response to Emergencies
        Recovery Team Members
        Recovery Team Responsibilities
        Damage Assessment
        Off-Hours Response to an Emergency
        Recovery Team Responsibilities
        Recovery Strategy
        Coordinate Equipment Needs
Disaster Recovery Decision Tree
Software Recovery
Hardware Recovery
Server Disaster Recovery
Preparation
        Documentation
        Software Management
        Knowledge Management
Server Backup
        Client Software Configuration
Restoring the Server
        Build the Server Hardware
        Post Restore
Active Directory Disaster Recovery
        Disaster Recovery Service Level Agreements
        Exchange Disaster Recovery Plan
        Complete RAID 5 Failure
        Complete RAID 1 Failure
        Complete System Failure
        NIC, RAID Controller Failures
Train Personnel and Practice Disaster Recovery

Disaster Recovery Planning

The first step of the disaster recovery process is to develop a formal disaster recovery plan. This plan, while time consuming to develop, serves as a guide for the entire organization in the event of an emergency. Disaster scenarios, such as power outages, hard drive failures, and even earthquakes, should be addressed. Although it is impossible to develop a scenario for every potential disaster, it is still helpful to develop a plan to recover for different levels of disaster. It is recommended that organizations encourage open discussions of possible scenarios and the steps required to recover from each one. Include representatives from each department, because each department will have its own priorities in the event of a disaster. The disaster recovery plan should encompass the organization as a whole and focus on determining what it will take to resume normal business function after a disaster.

Backup and Recovery

Backup procedures encompass not just backing up data to tape or other medium, but also a variety of other tasks, including advanced system recovery, offsite storage, and retention. These tasks should be carefully documented to accurately represent what backup methodologies are implemented and how they are carried out. Step-by-step procedures, guidelines, policies, and more may be documented.

Periodically, the backup documents should be reviewed and tested, especially after any configuration changes. Otherwise, backup documents can become stale and can only add more work and add to the problems during recovery attempts.

Recovery documentation complements backup documentation. This documentation should include where the backup data resides and how to recover from various types of failures (such as hard drive failure, system failure, and natural disaster). As with backup documentation, recovery documentation can take the form of step-by-step guides, policies, frequently asked questions (FAQs), and checklists. Moreover, recovery documents should be reviewed and revised if necessary.

Monitoring and Performance Documentation

Monitoring is not typically considered a part of disaster recovery documentation. However, alerting mechanisms can detect and bring attention to issues that may arise. Alerting mechanisms can provide a proactive means to determining whether a disaster may strike. Documenting alerting mechanisms and the actions to take when an alert is received can reduce downtime and administration.

Failover

Organizations using failover technologies or techniques such as clustering or network load balancing (NLB) can benefit from having documentation regarding failover. When a system fails over, knowing the procedures to get the system back up and running quickly can help you avoid unnecessary risk. These documented procedures must be thoroughly tested and reviewed in a lab setting so that they accurately reflect the process to recover each system.

Change Management Procedures

Changes to the environment may occur all the time in an organization, yet often those changes are either rarely documented or no set procedures are in place for making those changes. IT personnel not responsible for the change may be oblivious to those changes, and other administration or maintenance may be adversely affected.

Documented change management seeks to bring knowledge consistency throughout IT, control when and how changes are made, and minimize disruption from incorrect or unplanned changes. As a result, documenting change procedures should entail the processes to request and approve changes, high-level testing procedures, the actual change procedures, and any rollback procedures in case problems arise.


Performance Documentation

Documenting performance-related information is a continuous process due to the ever-changing metrics of business. This type of documentation begins by aligning with the goals, existing policies, and SLAs for the organization. When these areas are clearly defined and detailed, baseline performance values can be established using the System Monitor, Microsoft Operations Manager (MOM), or third-party tools (such as PerfMon and BMC Patrol). Performance baselines capture performance-related metrics, such as how much memory is being used, average processor utilization, and more; they also illustrate how the Windows Server 2003 environment is performing under various workloads.

After the baseline performance values are documented and understood, the performance-related information that the monitoring solution is still capturing should be analyzed periodically. More specifically, pattern and trend analysis needs to be examined on a weekly basis if not on a daily basis. This analysis can uncover current and potential bottlenecks and proactively ensure that the system operates as efficiently and effectively as possible.

Routine Reporting

Although the System Monitor can log performance data and provide reporting when used with other products such as Microsoft Excel, it behooves administrators to use products such as MOM for monitoring and reporting functionality. For example, MOM can manage and monitor multiple systems and provide graphical reports with customizable levels of detail.

Management-Level Reporting

Management-level reporting on performance data should be concise and direct but still at a high level. Stakeholders don't require an ample amount of performance data, but it's important to show trends, patterns, and any potential problem areas. This extremely useful information provides a certain level of insight to management so that decisions can be made as to what is required to keep the systems operating in top-notch condition. For instance, administrators identify and report to management that, if current trends on Exchange Server processor utilization continue at the current rate of a 5% increase per month, this will require additional processors in 10 months or less. Management can then take this report, follow the issue more closely over the next few months, and then determine whether to allocate funds to purchase additional processors. If the decision is made to buy more processors, management has more time to negotiate quantity, processing power, and cost instead of having to potentially pay higher costs for the processors at short notice.

Technical Reporting

Technical performance information reporting is much more detailed than management-level reporting. Details are given on many different components and facets of the system. For example, many specific counter values may be given to determine disk subsystem utilization. In addition, trend and pattern analysis should also be included to show historical information and determine how to plan for future requirements.


Security Documentation

Administrators can easily feel that documenting security settings and other configurations is important but that this documentation may lessen security mechanisms in the Windows Server 2003 environment. Nevertheless, documenting security mechanisms and corresponding configurations is vital to administration, maintenance, and any potential security compromise.

As with many of the documents about the network environment, they can do a lot of good for someone either externally or internally trying to gain unauthorized access. So, security documentation and many other forms of documentation, including network diagrams, configurations, and more, should be well guarded to minimize any security risk.

Some areas regarding security that should be documented include, but aren't limited to, the following:

  • Auditing policies including review

  • Service packs (SPs) and updates

  • Certificates and certificates of authority

  • Firewall and proxy configurations

  • Antivirus configurations

  • Access control policies including NTFS-related permissions

  • Encrypting File System (EFS)

  • Password policies (such as length, strength, and age)

  • GPO security-related policies

  • Registry security

  • Security breach identification procedures

  • Lockdown procedures

Change Control

Although the documentation of policies and procedures to protect the system from external security risks is of utmost importance, internal procedures and documents should also be established. Developing, documenting, and enforcing a change-control process helps protect the system from well-intentioned internal changes.

In environments with multiple administrators, it is very common to have the interests of one administrator affect those of another. For instance, an administrator might make a configuration change to limit volume size for a specific department. If this change is not documented, a second administrator might spend a significant amount of time trying to troubleshoot a user complaint from that department. Establishing a change control process that documents these types of changes eliminates confusion and wasted resources. The change control process should include an extensive testing process to reduce the risk of production problems.

Routine Reporting

A network environment may have many security mechanisms in place, but if the information such as logs and events obtained from them isn't reviewed, security is more relaxed. Monitoring and management solutions (such as MOM) can help consolidate this information into a report that can be generated on a periodic basis. This report can be invaluable to continuously evaluating the network's security.

The reports should be reviewed daily and should include many details for the administrators to analyze. MOM, for example, can be customized to report on only the most pertinent events to keeping the environment secure.

Management-Level Reporting

Management should be informed of any unauthorized access or attempts to compromise security. The technical details that an administrator appreciates are usually too detailed for management. Therefore, management-level reporting on security issues should contain only vital statistics and any risks that may be present. Business policy and budget-related decisions can then be made to strengthen the environment's security.


Training Documentation

Training documentation can entail a myriad of options. For example, an organization can have training documentation for maintenance and administration procedures, installation and configuration of new technologies, common end-user tasks, ways various network components can be used, future technologies, and much more. The documentation should match current training procedures, and it can also help define which trainings will be offered in the future.

Technical Training

Administrators are responsible for the upkeep and management of the network environment. As a result, they must be technically prepared to address a variety of issues such as maintenance and troubleshooting. Training documentation should address why the technologies are being taught and how the technologies pertain to the network environment, and it should also provide step-by-step hands-on procedures to perform the tasks.

End-User Training

Training materials and other forms of documentation for end users offer the users a means for learning an application, ways to map network drives, ways to locate information, and much more. End-user training documentation also serves as a great reference tool after training has been concluded.

System Usage Policies

To gain control over how the system is to be used, it's important for an organization to implement system usage policies. Policies can be set on end users as well as on the IT personnel. Policies for end users may include specifying which applications are supported on the network, that gaming is not allowed on the local machine or the network, and that users must follow specific steps to obtain technical support. On the other hand, IT personnel policies may include when to set database replication intervals or specify that routine system maintenance can occur only between 5:00 a.m. and 9:00 a.m. on Saturdays.


Summary

Most, if not all, aspects of a Windows Server 2003 network environment can be documented. However, the type of documentation that may benefit the environment depends on each organization. Overall, documenting the environment is an important aspect of the network and can assist all aspects of administration, maintenance, support, troubleshooting, testing, and design.


Best Practices

  • Have documentation reviewed and approved by other stakeholders in the organization to make sure that it meets their needs as well, and to simply get input from another source. For technical procedures, the document also must be tested and walked through.

  • Consolidate and centralize documentation for the organization.

  • Document the company's policies and procedures for securing and maintaining.

  • Create well-thought-out and professional planning and design documentation to avoid costly mistakes in the implementation or migration process, such as buying too many server licenses or purchasing too many servers.

  • Baseline and document the state of a Windows Server 2003 so that any changes in its performance can be identified at a later date.

  • Use tools such as Microsoft Project to facilitate the creation of project plans, enable the assignment of one or more resources per task, and the assignment of durations and links to key predecessors.

  • Create disaster recovery documentation that includes step-by-step procedures for rebuilding each server and network device to minimize downtime and administration.

  • Document daily, weekly, monthly, and quarterly maintenance tasks to ensure the health of the systems.

  • Use documentation to facilitate training.

  • Document business and technical policies for the organization.


Chapter 25. Integrating Microsoft Operations Manager with Windows Server 2003

In This Chapter

  • What Is Microsoft Operations Manager?

  • How MOM Works

  • Outlining MOM Architecture

  • How to Use MOM

  • Exploring Management Packs

  • MOM Component Requirements

  • Advanced MOM Concepts

  • MOM Security

  • Identifying Sample Designs of Successful MOM Implementations


What Is Microsoft Operations Manager?

Microsoft Operations Manager (MOM) provides an excellent approach to monitoring and managing Windows Server 2003 and Windows 2000based network environments. MOM helps to identify problems before they evolve into critical issues through the use of MOM's event consolidation, performance monitoring, and alerting features. MOM provides a real-time view of critical events and intelligently links them to appropriate Microsoft Knowledge Base articles. Cryptic event IDs are directly matched to known issues and immediately referred to technical reference articles in Microsoft's Knowledge Base for troubleshooting and problem resolution. MOM monitors Windows-based servers and applications using standard Windows services such as Windows Management Instrumentation (WMI) and Windows logged events. In addition, MOM also provides a reporting feature that allows network administrators to track problems and trends occurring on their network. Reports can be generated automatically, providing network administrators a quick, real-time view of their server performance data.

Note

Microsoft Operations Manager was originally developed by NetIQ, and then was purchased and released as MOM 2000. MOM was subsequently updated and released as MOM 2005. Both versions contain powerful management capabilities, with MOM 2005 providing additional functionality and scalability. It is recommended to deploy the latest version when possible, to take advantage of the additional features and enhanced performance.

MOM integrates with and manages Windows Server 2003. It can also be used in Windows 2000 Server or mixed environments to provide for automated monitoring of vital network functionality. This type of functionality is instrumental in reducing downtime and getting the most out of a Windows Server 2003 investment. In a nutshell, MOM is an effective way to gain proactive, rather than reactive, control over a mixed Windows Server 2003/Windows 2000 environment.

This chapter focuses on defining MOM as a service in a Windows Server 2003 network. It provides specific analysis of how MOM operates and presents MOM design best practices. In addition, this chapter presents sample Windows Server 2003 designs to give a real-world approach to MOM functionality and usability.


How MOM Works

MOM is an event and performance datadriven monitoring system that effectively allows for large-scale management of mission-critical servers. Organizations with a medium to large investment in Windows Server 2003 or Windows 2000 servers will find that MOM allows for an unprecedented ability to keep on top of the tens of thousands of event log messages that occur on a daily basis. In its simplest form, MOM performs two functions: processing gathered events and performance data, and issuing alerts and automatic responses based on those data.

MOM provides for several major pieces of functionality, as follows:

  • Event Log Consolidation MOM Agents, deployed on managed systems, forward all event log information to a central MOM SQL Server database, which is managed and groomed by MOM. This data is used for reporting, auditing, and monitoring the specific events.

  • Advanced Alerting Capabilities MOM provides advanced alerting functionality by enabling email alerts, paging, and functional alerting roles to be defined.

  • Performance Monitoring MOM collects performance statistics that can let an administrator know whether a server is being overloaded or is close to running out of disk space, among other things.

  • Built-in Application-specific Intelligence MOM management packs are packages of information about a particular application or service, such as Windows Server 2003, FRS, DNS, DHCP, Exchange Server, or other applications. The Microsoft management packs are written by the design teams for each individual product, and they are loaded with the intelligence and information necessary to properly troubleshoot and identify problems.

Processing Events and Performance Data

MOM manages Windows Server 2003 networks through event consolidation and performance data gathering. It collects application, system, and security events throughout the Windows Server 2003 network and writes them to a single database repository. Processing rules define how MOM collects, handles, and responds to the information gathered. MOM processing rules handle incoming event data and allow MOM to react automatically, either to respond to a predetermined problem scenario, such as a failed hard drive, with a predefined action (trigger an alert, execute a command or script) or to consolidate multiple events into one event that correlates a group of related events. The processing rules also enable MOM to automatically determine which events are important to a network administrator, minimizing administrative overhead.

Generating Alerts and Responses

MOM processing rules can generate alerts based on critical events or performance thresholds that are met or exceeded. An alert can be generated by a single event or by a combination of events or performance thresholds. For example, a failed fan can generate a simple alert, whereas a failed database generates a more complex alert relating to the failed SQL database services and IIS Web pages that rely on the availability of the database. Alerts can also be configured to trigger responses such as email, pages, Simple Network Management Protocol (SNMP) traps, and scripts to notify administrators of potential problems.

MOM can be configured to notify various IT groups. For example, an alert triggered by a failed database can alert the help desk with email and the database administrator with email and a paged message. In brief, MOM is completely customizable in this respect and can be modified to fit most alert requirements.


Outlining MOM Architecture

MOM is primarily composed of four basic components: the database, data access server, consolidator/agent manager, and MOM agents. MOM was specifically designed to be scalable and can subsequently be configured to meet the needs of any size company. This flexibility stems from the fact that all MOM components can either reside on one server or can be distributed across multiple servers. Microsoft separates the components into a distributed multitier architecture based on the standard network OSI model, condensed into the Presentation, Business Logic, and Data layers, in this case. Each layer of the model corresponds with MOM components, as illustrated in Figure 25.1.

Figure 25.1. The Microsoft Operations Manager architecture.

The MOM administrator console, Web console, and the Reporting feature make up the Presentation Layer components. The consolidator/agent manager, data access server, and agents make up the Business Logic layer. Lastly, the database and data providers comprise the Data layer.

Each of these various components provides specific MOM functionality. MOM design scenarios often involve the separation of parts of these components onto multiple servers. For example, the database component can be delegated to a dedicated server, and the data access server and consolidator can reside on a second server. More details on these concepts can be found in the "Identifying Sample Designs of Successful MOM Implementations" section later in this chapter.

How MOM Stores Captured Data

MOM utilizes a Microsoft SQL Server database as the central repository for all collected data. This data includes all event log and performance data gathered from each managed computer. The database also stores all the scripts used by the management pack rules. This database must be installed as a separate component from MOM but can physically reside on the same server, if needed. Proper SQL procedures and maintenance for this database component are critical for proper MOM functionality.

Note

For testing purposes, an MSDE database can be used with MOM to provide for MOM's database needs. However, it is highly recommended that a full SQL database be used in a production environment, as there are several restrictions associated with the MSDE database.

The Role of the Data Access Server

The data access server (DAS) is the MOM component that is used to communicate with the MOM database. It handles all the data transactions between the database and all the other MOM services. Most requests to read information from the database use DAS (with the major exception of Reporting), as well as all requests to write data to the database.

The Consolidator Component

The consolidator is responsible for controlling and updating all the managed computers in a MOM database. It delivers all client agent updates, which include updating any rules or configuration settings to the managed computers. It also delivers all data gathered by the managed computers to the DAS.

Determining the Role of Agents in System Monitoring

The agents are the monitoring components installed on each managed computer. They use the collected event logs and performance counter data and process them based on the management pack rules installed on the computer.

Creating Administrative Boundaries with Configuration Groups

MOM utilizes the concept of configuration groups to logically separate geographical and organizational boundaries. Configuration groups allow administrators to scale the size of MOM architecture or politically organize the administration of MOM. Each configuration group consists of the following components:

  • One database

  • One or more consolidator/agent managers (CAMs)

  • One or more data access servers (DASs)

  • Managed agents

As noted in the "Identifying Sample Designs of Successful MOM Implementations" section later in this chapter, MOM can be scaled to meet the needs of different sized organizations. For small organizations, all the MOM components can be installed on one server with a single configuration group, as illustrated in Figure 25.2.

Figure 25.2. Single configuration group.

In large organizations, on the other hand, the distribution of MOM components to separate servers allows the organizations to customize their MOM architecture, as illustrated in Figure 25.3. Multiple configuration groups provide load balancing and fault tolerance within the MOM infrastructure. Organizations can set up multiple consolidators, data access servers, or agent managers at strategic locations, to distribute the workload between them.

Figure 25.3. Multiple configuration groups.

Note

The general rule of thumb with configuration groups is to start with a single configuration group and add on more configuration groups only if they are absolutely necessary. Administrative overhead is reduced, and there is less need to re-create rules and perform other redundant tasks with fewer configuration groups.


How to Use MOM

Using MOM is relatively straightforward. It can be configured through two sets of consoles: a Microsoft Management Console (MMC) snap-in and a Web console. All MOM activities are easily accessible through these consoles. After a MOM environment is deployed, very little needs to be done to monitor the system; it is easy to forget that MOM is deployed. The real value of the system presents itself when a critical system event is logged and an administrator is notified.

Managing and Monitoring with MOM

As mentioned in the preceding section, two methods can be used to configure and view MOM settings. The first approach is through either an Administrator Console, shown in Figure 25.4, or Operator Console, shown in Figure 25.5. With the Administrator Console, administrators can easily navigate through a hierarchical tree structure and configure the rules, notification groups, and configuration settings. With the Operator Console, quick up/down status and overall environment health can be monitored easily.

Figure 25.4. The MOM 2005 Administrator Console.

[View full size image]

Figure 25.5. The MOM 2005 Operator Console.

[View full size image]

In addition to the main MMC-based console, a Web-based administration console with a Web browser such as Microsoft Internet Explorer (versions 4.01 or higher) can be used to view and configure key MOM information. Through the Web console, administrators can review the status of managed systems with the ability to take action on and update alerts. Access to the associated Knowledge Base is provided as well.

Reporting from MOM

MOM has a variety of preconfigured reports and charts. The reports allow administrators a quick review of the status of systems and services on the network. They can also help administrators monitor their networks based on performance data. The reports can be run on demand or at scheduled times. MOM can also generate HTML-based reports that can be published to a Web server and viewed from any Web browser. Vendors can also create additional reports as part of their management packs.

Using Performance Monitoring

Another key feature of MOM is the capability to monitor and track server performance. MOM can be configured to monitor key performance thresholds through rules that are set to collect predefined performance data, such as memory and CPU usage over time. Rules can be configured to trigger alerts and actions when specified performance thresholds have been met or exceeded, allowing network administrators to act on potential hardware issues. Performance data can be viewed from the MOM Operator Console, as shown in Figure 25.5.


Exploring Management Packs

MOM would be ineffectual if all it did was blindly gather event log information. As any administrator can attest, some event logs and performance data, at first glance, appear serious but turn out to be something that can be safely ignored. Other times, innocuous-looking information events can be symptoms of critical underlying problems. The real value in MOM lies in its capability to intelligently process these data and provide proactive responses to defined threats. For example, if a specific event ID is understood to be associated with virtual memory fragmentation, MOM can be programmed to report this fact in advance and provide for an intelligent response and course of action to alleviate the issue. These preprogrammed intelligent responses are programmed into MOM management packs.

Management packs are preconfigured rules that define how MOM processes incoming data from managed computers. Management packs also contain Knowledge Base information on the possible cause and resolutions of predetermined events. Out of the box, MOM includes a standard list of management packs that cover all critical Windows services, such as

  • Windows 2000/2003/R2

  • Active Directory

  • File Replication Service (FRS)

  • Domain Name System (DNS)

  • Windows Internet Naming Service (WINS)

  • Internet Information Services (IIS)

  • Dynamic Host Configuration Protocol (DHCP)

  • Routing and Remote Access Server (RRAS)

  • Microsoft Transaction Service (MTS)

  • Microsoft Message Queuing (also known as MSMQ)

  • Microsoft Distributed Transaction Coordinator (MSDTC)

  • Systems Management Server (SMS)

  • Microsoft Operations Manager (MOM) 2000/2005

  • Terminal Server

  • Microsoft Windows NT 4.0 (OS System Logs)

Additional application management packs are also available from Microsoft. These management packs have been developed by the experts in their respective fields (such as Microsoft SQL and Microsoft Exchange 2000/2003). Like the standard management packs, the application management packs come with preconfigured rules and Knowledge Base information that help monitor and manage the applications running on Windows 2000 and Windows Server 2003. Additional management packs are available from other vendors such as NetIQ, for a wide range of enterprise applications. The following is a list of application management packs available from Microsoft:

  • Exchange 5.5/2000/2003

  • SQL Server 2000/2005

  • SQL Server 7.0

  • Application Center 2000

  • Internet Security and Acceleration (ISA) Server 2000/2004

  • Proxy Server 2.0

  • Site Server 3.0

  • Commerce Server 2000

  • SNA Server 4.0

  • Host Integration Server (HIS) 2000

  • SharePoint Portal Server 2003/Windows SharePoint Services

  • Microsoft .NET Framework

  • Network Load Balancing

  • Windows Server clusters

  • Microsoft Identity Integration Server (MIIS) 2003

Microsoft is constantly updating and adding new management packs as part of the Microsoft Dynamic Systems Initiative (DSI). These management packs can be downloaded from the Management Pack Catalog at http://www.microsoft.com/mom/downloads/managementpacks/default.asp.

The latest versions of management packs should always be used, as they include many improvements and updates from the release code. In fact, the release code does not include the core management packs for Windows 2003 or Exchange 2003 on the CD. This makes it imperative to download the updated management packs.

Other hardware and software vendors also create their own management packs with predefined rules, alerts, and actions. These vendors also include the knowledge about their products, helping network administrators to quickly resolve problems. In addition, administrators can create their own rules and alerts or customize existing ones.

Legacy Management Integration

Network management is not a new concept. Simple management of various network nodes has been handled for quite some time through the use of the Simple Network Management Protocol (SNMP). Quite often, simple or even complex systems that utilize SNMP to provide for system monitoring are in place in an organization to provide for varying degrees of system management on a network.

MOM can be configured to integrate with these network systems and management infrastructures. Special connectors can be created to provide bidirectional information flows to other management products. MOM can monitor SNMP traps from SNMP-supported devices as well as generate SNMP traps to be delivered to third-party network management infrastructures. In addition, MOM can also monitor live events on Unix systems using the syslog protocol.

Extended Management Packs

MOM was specifically developed to provide for the development and native utilization of multiple management pack snap-ins, known as Extended Management Packs (XMPs), within a MOM infrastructure. This provides for the flexibility to scale a MOM deployment to multiple specialized applications. For example, a specialized third-party database program can be monitored through the use of an XMP that is specifically designed to respond to criteria specific to that application, such as event IDs that indicate possible database corruption.

Software and hardware developers can subsequently create their own management packs to extend MOM's management capabilities. XMPs extend MOM's management capabilities beyond Microsoft-specific applications. Each management pack is designed to contain a set of rules and product knowledge required to support its respective products. Currently, XMPs have been developed for the following products, with many more in development:

  • Novell NetWare

  • Linux

  • Compaq Insight Manager

  • Oracle RDBMS

  • Antivirus Applications from Trend, McAfee, and Norton

  • Management tools from Tivoli, MicroMuse, Hewlett-Packard, and NetIQ

MOM Resource Kit Tools

MOM has several resource kits that are available that enhance the functionality for monitoring and managing a networking environment. Some of the tools include the following:

  • Server Status Monitor (SSM) tool The SSM tool allows for the simple up/down monitoring of a small group of servers, similar to SNMP monitoring from products such as HP OpenView's Network Node Manager.

  • RunMOMScript This tool allows for the testing of scripts designed to run with MOM rules. The tool processes each script as MOM would, allowing for effective testing.

  • Pocket MOM This is a PocketPC-based tool that allows for the management of a MOM environment directly from a handheld PocketPC device.

  • MOM-to-Tivoli connector This connector allows a MOM 2000 SP1 environment to coexist with a Tivoli Enterprise Console (TEC) environment.

  • EventSim The Event Simulations tool tests MOM management packs by replaying Windows events into MOM and load-testing a MOM event rule environment.

  • ConfigureEventLogs This tool allows for the mass configuration of multiple servers serviced by MOM.

  • MOM DTS The Microsoft Operations Manager Data Transformation Services Package tool allows data to be offloaded from a production MOM database to a separate offline database. This allows for long-term retention of server events and performance data.


MOM Component Requirements

Each MOM component has specific design requirements, and a good knowledge of these factors is required before beginning the design of a MOM. Hardware and software requirements must be taken into account, as well as factors involving specific MOM components such as service accounts and backup requirements.

Hardware Requirements

Having the proper hardware for MOM to operate on is a critical component of MOM functionality, reliability, and overall performance. Nothing is worse than overloading a brand-new server only a few short months after its implementation. The industry standard generally holds that any production servers deployed should remain relevant for three to four years following deployment. Stretching beyond this time frame may be possible, but the ugly truth is that hardware investments are typically short term and need to be replaced often to ensure relevance. Buying a less-expensive server may save money in the short term but could potentially increase costs associated with downtime, troubleshooting, and administration. That said, the following are the Microsoftrecommended minimums for any server running MOM 2005:

  • 1GHz+ Pentium or compatible processor

  • 10GB of free disk space

  • 1GB of random access memory (RAM)

These recommendations apply only to the smallest MOM deployments and should be seen as minimum levels for MOM hardware. Future expansion and relevance of hardware should be taken into account when sizing servers for MOM deployment.

Determining Software Requirements

MOM can be installed either on Windows Server 2003 or Windows 2000 with Service Pack 2 or higher. Installing on Windows Server 2003 for new deployments of MOM is highly recommended, to take advantage of the improvements in the operating system (this is a book on Windows Server 2003, after all).

The database for MOM must be run on a Microsoft SQL Server 2000/2005 database. The database can be installed on the same server as MOM or on a separate server, a concept that will be discussed in more detail in following sections. While technically possible to run MOM on an MSDE, developer-related database, using the more robust SQL database structure for MOM information is highly recommended.

Note

MOM 2005 installs on SQL 2000 SP3a or higher without problems. Installation on SQL 2005 will fail unless the installation is run from the MOM 2005 SP1 media. Although it will install on MOM 2005 SP1, the "official" word from Microsoft is that MOM is not supported on SQL 2005 until Service Pack 2.

MOM itself must be installed on a member server in a Windows Server 2003 (or Windows 2000) Active Directory domain, and not on a domain controller, because it will not physically install if this is the case. It is most often recommended to keep the installation of MOM on a separate server or set of separate dedicated member servers that do not run any other separate applications.

A few other factors critical to the success of a MOM implementation are follows:

  • WINS must be installed in environments that utilize any Windows NT nodes.

  • SQL 2000 Reporting Services or higher must be installed for an organization to be able to produce custom reports using MOM's reporting feature.

  • Email notifications require the use of Microsoft Outlook 98 or higher.

Identifying MOM Service Accounts

The consolidator and data access server components of MOM require the use of a dedicated service account. The same account can be used for these services, and doing so is actually recommended. However, for security reasons, it is theoretically possible to use two different service accounts from different domains. The caveat with this approach, however, is that each service account that accesses the SQL database requires a separate SQL client access license (CAL).

MOM Backup Considerations

Like most technical implementations, MOM includes several key components that require regular backups for disaster recovery scenarios. The system state and system drive of each MOM server should be backed up to provide for quick recovery of MOM configuration information. Special add-ons to backup software specifically written for Microsoft Operations Manager can ensure the ability to back up live data from MOM systems. At this time, many of the large backup software manufacturers offer this type of specialized add-on to their products, and it would be prudent to integrate these components into a MOM design.

In addition, the most critical piece of MOM, the SQL database, should be regularly backed up using an additional add-on to standard backup software that can effectively perform online backups of SQL databases. If integrating these specialized backup utilities into a MOM deployment is not possible, it becomes necessary to periodically dismount the MOM database and perform offline backups. Either way, the importance of backups in a MOM environment cannot be overstressed.

Deploying MOM Agents

MOM agents are deployed to all managed servers through the MOM configuration process. These agents can be configured to be automatically installed for all Windows Server 2003 and Windows 2000 servers on a specific domain based on managed computer rules. These rules use the NetBIOS name of the computer and the domain to allow you to select which systems should have the client installed automatically. You can use wildcards to specify a broad range of computers. Certain situations, such as monitoring across firewalls, can require the manual installation of these components.

Note

Agent installation is contingent on the MOM service accounts having local Admin rights on the servers in which they will be installed. If applying these rights is not possible, even temporarily, MOM must be installed manually, using an account that possesses these rights.


Advanced MOM Concepts

MOM's simple installation and relative ease of use often betray the potential complexity of its underlying components. This complexity can be managed, however, with the right amount of knowledge of some of the advanced concepts of MOM design and implementation.

DCAM Versus D-DCAM Servers

As previously mentioned, MOM components can be divided across multiple servers to distribute load and ensure balanced functionality. This separation allows MOM servers to come in three potential "flavors," depending on the MOM components held by those servers. The three MOM server types are as follows:

  • Database server A MOM database server is simply a member server with SQL Server 2000/2005 installed for the MOM database. No other MOM components are installed on this server. The SQL Server 2000/2005 component must be installed with default options and with a SQL service account. The service account, in addition to any other service accounts utilized by DAS and the consolidator, require the use of a client access license.

  • DCAM server Also known as simply a DCAM, this type of server is named after the MOM components used by the server. The DAS, consolidator, and agent manager components all reside on a DCAM. In addition, the console and user interfaces are also held by this server. Effectively, a DCAM is a MOM server without a database and is often used in large MOM implementations that have a dedicated database server. Often, in these configurations, multiple DCAMs are used in a single configuration group to provide for scalability and to address multiple managed nodes.

  • D-DCAM server A D-DCAM server is effectively a MOM server that holds all MOM roles, including that of the database. Subsequently, single-server MOM configurations use one D-DCAM for all MOM operations, excluding reporting.

Multiple Configuration Groups

As previously defined, a MOM configuration group is a logical grouping of monitored servers that are managed by a single MOM SQL database, one or more DCAMs, and a unique configuration group name. Each configuration group established operates completely separately from other configuration groups, although they can be configured to forward alerts between each other.

The concept of alert forwarding between configuration groups allows MOM to scale beyond artificial boundaries and also gives a great deal of flexibility when combining MOM environments. However, certain caveats must be taken into account. Because each configuration group is an island in itself, each must subsequently be manually configured with individual settings. In environments with a large number of customized rules, for example, such manual configuration would create a great deal of redundant work in the creation, administration, and troubleshooting of multiple configuration groups.

Deploying Geographic-Based Configuration Groups

Based on the factors outlined in the preceding section, it is preferable to deploy MOM in a single configuration group. However, in some situations it is preferable not to divide a MOM environment into multiple configuration groups, or dividing it this way is unavoidable.

The most common reason for division of MOM configuration groups is division along geographic lines. In situations in which WAN links are saturated or unreliable, it may be wise to separate large "islands" of WAN connectivity into separate configuration groups.

Simply being separated across slow WAN links is not enough reason to warrant a separate configuration group, however. For example, small sites with few servers would not warrant the creation of a separate MOM configuration group, with the associated hardware, software, and administrative costs. However, if many servers exist in a distributed, generally well-connected geographical area, that may be a case for the creation of a configuration group. For example, an organization could be divided into several sites across the U.S. but decide to divide the MOM environment into separate configuration groups for east coast and west coast, to roughly approximate their WAN infrastructure.

Smaller sites that are not well connected but are not large enough to warrant their own configuration group should have their event monitoring throttled to avoid being sent across the WAN during peak usage times. The downside to this approach, however, is that the reaction time to critical event response is increased.

Deploying Political or Security-Based Configuration Groups

The less common method of dividing MOM configuration groups is by political or security lines. For example, it may become necessary to separate financial servers into a separate configuration group to maintain the security of the finance environment and allow for a separate set of administrators.

Politically, if administration is not centralized within an organization, configuration groups can be established to separate MOM management into separate spheres of control. This would keep each MOM management zone under separate security models, and alert forwarding could be set up to exchange information between different configuration groups.

As previously mentioned, a single configuration group is the most efficient MOM environment and provides for the least amount of redundant setup, administration, and troubleshooting work. Consequently, artificial MOM division along political or security lines should be avoided, if possible.

Sizing the MOM Database

All new technologies seem to consume tremendous amounts of disk space, and MOM is no exception to this trend. Depending on several factors, such as the type of data collected, the length of time that collected data will be kept, or the amount of database grooming that is scheduled, a MOM database can grow by leaps and bounds, if left unchecked. Microsoft recommends a database volume of 5GB, although it is highly recommended to consider leaving more than enough space for the database to grow. An organization might want, for example, to keep event information for longer periods of time, which would drive up the size of the database exponentially.

Estimating the Size of a MOM Database

The formula Microsoft uses for MOM database sizing shows the approximate amount of disk space a database will consume. Bear in mind that 40% should be added to the numbers that are produced by this formula as MOM indexing requires 40% free space on the database volume.

(((e*s)1400)g)

where:

e = Total number of events, security events, performance counters, and unsuppressed alerts per minute

s = Average kilobyte size of each event, counter, and alert

1400 = Number of minutes in a day

g = Grooming interval, expressed in number of days

It is important to monitor the size of the database to ensure that it does not increase well beyond the bounds of acceptable size. As previously mentioned, MOM requires a minimum of 40% free space on the database volume to properly index, and it is imperative that a database not grow too large to affect this performance. The following actions can be taken to reduce the size of a MOM database:

  • Archive collected data The more often old data is archived, the smaller a database will become, for obvious reasons. When a MOM database becomes too large, for example, it may become necessary to archive old data to alternate storage mediums. The downside to this approach, however, is the fact that reporting can generate historical reports only up to the point of the last archival. Finding the right tradeoff between an aggressive archiving schedule and an expansive database is recommended.

  • Modify the grooming interval As evident from the formula just presented, increasing the database grooming interval decreases the size of a database significantly. Setting the grooming interval to once every few days, for example, can aggressively address space limitations and keep the database consistent. Setting a regular grooming interval is subsequently key to an effective database maintenance strategy.

MOM can be configured to monitor itself, supplying advance notice of database problems and capacity thresholds. This type of strategy is highly recommended because MOM could easily collect event information faster than it could get rid of it.

Capacity Limits

As with any system, MOM includes some hard limits that should be taken into account before deployment begins. Surpassing these limits could be cause for the creation of new configuration groups and should subsequently be included in a design plan. These limits are as follows:

  • Single database per configuration group MOM operates through a principle of centralized, rather than distributed, collection of data. All event logs, performance counters, and alerts are sent to a single centralized database, and there can subsequently be only a single SQL database per configuration group. Considering the use of a backup and high-availability strategy for the MOM database is therefore highly recommended, to protect it from outage.

  • Six DCAMs per configuration group MOM is hard-coded to be limited to six DCAM servers per configuration group. If the pool of monitored servers increases beyond the capabilities of six DCAMs, adding an additional configuration group will become necessary, to handle all monitoring in the environment. Any configuration group with six DCAMs would be more likely limited by the size and throughput of the database, which by that point would most likely be enormous.

  • 700 agents per DCAM Each DCAM can theoretically support up to 700 monitored agents for every DCAM server. In most configurations, however, it is wise to limit the number of agents per DCAM to 200, although the levels can be scaled upward with more robust hardware, if necessary.

  • 30 console instances per DCAM MOM limits the number of instances of the Web and MMC Admin consoles to 30 per DCAM.

Scaling MOM Environments

MOM is scalable in the sense that multiple configuration groups can be configured to forward alerts between themselves. Within the configuration groups, multiple DCAM servers can be established as well to allow for a finer degree of scalability within each configuration group. These factors enable MOM to scale to organizations of all shapes and sizes.

MOM builds upon its multiple layers of scalability. In small deployments, a single DDCAM server will suffice. As the number of monitored servers increases, the database can be separated and additional DCAM servers can be added, roughly one per every 100 agents deployed. This can be continued until a total of six DCAM servers are deployed in a configuration group, as illustrated in Figure 25.6.

Figure 25.6. Multiple DCAMs.

When the physical limits of a configuration group have been reached, or when additional factors such as security, geographic, or political considerations move an organization to choose an additional configuration group, the final level of MOM scalability is reached. Division into multiple configuration groups allows an organization to scale a MOM deployment beyond the physical limitations of the configuration group itself.

System Redundancy

In addition to the scalability built into MOM, redundancy is built into the components of the environment. Proper knowledge of how to deploy MOM redundancy and place MOM components correctly is important to the understanding of MOM redundancy.

Having multiple DCAM servers deployed across a configuration group allows an environment to achieve a certain level of redundancy. If a single DCAM server experiences down-time, another DCAM server within the configuration group will take over the consolidator, DAS, and agent manager components for the monitored servers in the environment. For this reason, it may be wise to include multiple DCAM servers in an environment to achieve a certain level of redundancy if high uptime is a priority, as illustrated in Figure 25.7.

Figure 25.7. MOM failover.

Because there can be only a single MOM database per configuration group, the database is subsequently a single point of failure and should be protected from downtime. Utilizing Windows Server 2003 clustering or third-party fault-tolerance solutions for SQL databases helps to mitigate the risk involved with the MOM database.


MOM Security

Security has evolved into a primary concern that can no longer be taken for granted. The inherent security in Windows Server 2003 is only as good as the services that have access to it; therefore, it is wise to perform a security audit of all systems that access information from servers. This concept holds true for management systems as well because they collect sensitive information from every server in an enterprise. This includes potentially sensitive event logs that could be used to compromise a system. Consequently, securing the MOM infrastructure should not be taken lightly.

Physically Securing MOM

Aside from actual software security, one of the most important forms of security is actual physical security. MOM servers should be physically secured behind locked doors, and login access to the console should be curtailed to help protect the critical information contained within the environment. This concept cannot be overstressed, as physical security is one of the most highly overlooked but yet one of the most critical components of a secure infrastructure.

In addition to physical security, MOM servers should be carefully locked down at the OS level to prevent unauthorized access. This includes the creation of complex passwords for service accounts and the application of the latest service packs and security updates using the automatic update features in Windows Server 2003 to help keep the environment secure and up to date. In addition, administration of MOM security can be greatly simplified via the creation of an Active Directory group that controls MOM administration. This group can be granted admin rights to MOM servers, and users can be added as members to this group. Simplifying the administration of security often strengthens security as well because administrators take fewer security shortcuts when troubleshooting problems.

Securing MOM Agents

Each server that contains a MOM agent and forwards events to MOM DCAMs has specific security requirements. Server-level security, discussed in more detail in Chapter 12, "Server-Level Security," should be established and should include provisions for MOM data collection. All traffic between MOM components, such as the agents, the DCAMs, and the database, are encrypted automatically for security, so the traffic is inherently secured.

In addition, environments with high security requirements should investigate the use of encryption technologies such as IPSec to scramble the event IDs that are sent between agents and MOM servers, to protect against eavesdropping of MOM packets. More information can be found on setting up IPSec in Chapter 13, "Transport-Level Security."

Firewall Requirements

MOM servers that are deployed across a firewall have special considerations that must be taken into account. Port 1270, the default port for MOM communications, must specifically be opened on a firewall to allow MOM to communicate across it. In addition, MOM servers can be specifically configured to exist in a DMZ firewall configuration, as long as the proper access is granted to the managed servers from the DMZ.

Service Account Security

In addition to the aforementioned security measures, security of a MOM environment can be strengthened by the addition of multiple service accounts to handle the different MOM components. For example, the DAS and consolidator can be configured to use separate service accounts, to provide for an extra layer of protection in the event that one account is compromised. The caveat to this approach, however, is that the SQL database requires an additional CAL for each service account that accesses it.


Identifying Sample Designs of Successful MOM Implementations

For many medium-sized Windows Server 2003 and Windows 2000 server deployments, a single configuration group and single MOM server can provide an effective solution to proactive management. However, in some situations it could become wise to deploy multiple MOM servers, configuration groups, and agents to handle the specific needs of an organization. The examples in the following sections highlight some common best-case MOM design scenarios.

Deploying a Single Server MOM Configuration

CompanyXYZ is a 500-user organization that operates out of a single location in Reno, Nevada. A single Windows Server 2003 Active Directory domain named companyxyz.com is deployed across the entire organization. All the member servers run Windows Server 2003 and handle many specific functions, such as Active Directory, DNS, DHCP, WINS, Exchange Server 2003 email, and several other third-party software solutions.

Because of a recent rise in server and software malfunctions, the decision was made to deploy Microsoft Operations Manager 2005 to provide for a level of proactive management that would normally not be possible in the organization.

The total number of managed servers in CompanyXYZ's environment was 46, and it was therefore decided to deploy a single D-DCAM server in a single MOM configuration group because this would be the most cost-effective and rational design for a MOM deployment on this scale.

The server chosen to handle all MOM activities was a robust, redundant, industry standard machine with plenty of extra disk space for the database. Windows Server 2003 was installed as the operating system, as were the SQL Server database components. Upon the successful completion of the OS and database installations, a special tool included with MOM, the Prerequisite Checker, was run to ensure that the system was ready for MOM installation. After this was confirmed, MOM 2005 was installed and configured onto the single MOM server. A single service account was created in the AD domain and utilized for the DAS and consolidator components of MOM. All applicable default management packs, such as DNS and DHCP, were installed and configured. Additional management packs, such as those for Exchange 2003, were downloaded and installed as well. The final MOM design for CompanyXYZ began to take shape, as illustrated in Figure 25.8.

Figure 25.8. CompanyXYZ design.

Upon the successful completion of the MOM server installation, specialized rules were written to handle the particular components that are unique to CompanyXYZ's environment. Alert settings were configured so that a select group of administrators would be notified in the event of problems.

As a result of the MOM design chosen, CompanyXYZ feels confident that it will be able to easily scale its MOM deployment to a much larger number of servers, if required. The company is somewhat concerned about the single point of failure that the single MOM database occupies but is convinced that it chose the best and most cost-effective solution for its organization.

Deploying a Multiple MOM Server Configuration

CompanyABC is a large, multinational corporation with 10,000 users spread across continents. Major locations exist in New York, London, and Tokyo, and many other smaller branch offices are distributed across the world. Each of the major locations currently hosts between 100 and 200 servers each, and the smaller branch offices host smaller numbers of servers, totaling no more than 10 in each office. The servers deployed are a mix of Windows Server 2003 and Windows 2000 servers, although occasional Windows NT, Novell NetWare, and Linux servers are distributed across the environment.

Because of its distributed nature, CompanyABC is composed of multiple Windows Server 2003 Active Directory subdomains, all within the same Active Directory forest. The forest structure for CompanyABC, illustrated in Figure 25.9, is composed of subdomains na.companyabc.com, eu.companyabc.com, and asia.companyabc.com, all subdomains within the placeholder domain companyabc.com.

Figure 25.9. The CompanyABC forest.

Because of the loss of productivity that any server downtime entails for CompanyABC, an enterprise management platform was necessary for the organization to achieve the high levels of uptime required. Microsoft Operations Manager was chosen for this task.

Because the company's network environment was logically and geographically divided into three separate zones, it decided to use three MOM configuration groups for each geographic location and to use alert forwarding between each configuration group. Asia, Europe, and North America were designated as the configuration groups and were configured to manage not only the local hub servers, but also all the servers in the smaller offices that are closest to them on the WAN.

Each configuration group was set up with three DCAM servers to provide for redundancy and to allow for management of the 300 or so servers within the scope of each location's configuration group.

In addition to the DCAM servers, each configuration group was outfitted with a robust, completely redundant database server with a large quantity of disk space to handle the collected data from each configuration group. Each MOM server was installed with Windows Server 2003 and the appropriate MOM components.

Security was configured to be granular, and each location was given control over its corresponding configuration group through the use of separate Active Directory Security Groups from each domain, which were granted control over the various MOM components in their particular configuration group.

Because the applications installed across the CompanyABC environment were diverse and numerous, the number of management packs added to MOM was subsequently large. The default management packs were used, in addition to the Microsoft add-on packages and several XMPs purchased from the NetIQ corporation. This allowed for the management of the disparate operating systems that were deployed across the environment.

In the event of DCAM downtime, the CompanyABC MOM environment continues to function because the other two DCAMs in the affected configuration group take up the slack. In addition, the alert forwarding configured among the three configuration groups helps to centralize the administrations across the continents.


Summary

Microsoft Operations Manager has been road-tested with Windows networks and has proven its value in proactively identifying potential server issues before they degrade into server downtime. MOM for Windows Server 2003 extends the built-in reliability of the OS and allows for greater control over a large, distributed server environment. In addition, proper understanding of MOM components, their logical design and configuration, and other MOM placement issues can help an organization to fully realize the advantages that MOM can bring to a Windows Server 2003 environment.


Best Practices

  • Take future expansion and relevance of hardware into account when sizing servers for MOM deployment.

  • Use a Microsoft SQL Server database for MOM instead of the MSDE Database.

  • Keep the installation of MOM on a separate server or set of separate dedicated member servers that do not run any other separate applications.

  • Use WINS in environments that utilize Windows NT nodes.

  • Use SQL Server Reporting Services to produce custom reports using MOM's reporting feature.

  • Use Microsoft Outlook 98 or higher to use email notifications.

  • Start with a single configuration group and add on additional configuration groups only if they are absolutely necessary.

  • Use a dedicated service account for MOM.

  • Use a database volume of at least 5GB depending on the length of time needed to store events.

  • Monitor the size of the MOM database to ensure that it does not increase beyond the bounds of acceptable size.

  • Archive collected data.

  • Modify the grooming interval to aggressively address space limitations and keep the database consistent.

  • Configure MOM to monitor itself.


Part VII: Remote and Mobile Technologies

In This Part

CHAPTER 26 Remote and Mobile Access

CHAPTER 27 Windows Server 2003 Terminal Services


Chapter 26. Remote and Mobile Access

In This Chapter

  • Windows Server 2003 Routing and Remote Access Features and Services

  • Routing and Remote Access Service Architecture

  • Virtual Private Networking in Windows 2003

  • Authentication Options to an RRAS System

  • VPN Protocols

  • Choosing Between PPTP and L2TP/IPSec

  • Installing and Configuring Routing and Remote Access

  • Configuring Remote Access Clients

  • RRAS Tools and Utilities

  • Leveraging the Capabilities of the Quarantine Policy Check Tool

  • Remote Access Scenarios

As the Internet grows year after year, so does the need to work productively away from the office. Companies are always looking for alternative cost-effective methods of connecting their remote and mobile users and offices without sacrificing performance or security. Microsoft Windows Server 2003's Routing and Remote Access Service (RRAS) offers integrated multiprotocol routing and remote access services for Microsoft Windowsbased computers; RRAS provides multiprotocol LAN-to-LAN, LAN-to-WAN, virtual private network (VPN), and Network Address Translation (NAT) routing services. RRAS enables companies to provide remote access services to their remote and mobile users; it also provides an alternative for connecting their branch offices. RRAS also works with a wide variety of hardware platforms and network adapters as well as various media types such as Ethernet, FDDI, ATM, frame relay, xDSL, and cable modems. In addition, RRAS is extensible, providing an application programming interface (API) that third-party developers can use to create custom networking solutions.


Windows Server 2003 Routing and Remote Access Features and Services

Windows Server 2003 builds on the Routing and Remote Access features that were provided by Windows NT 4.0 and Windows 2000. Routing and Remote Access in Windows Server 2003 includes all the features and services from all previous versions of the Windows server product combined.

The following features were provided by Windows NT 4.0:

  • RIP version 2 routing protocol for IP

  • Open Shortest Path First (OSPF) routing protocol for IP

  • Demand-dial routing and routing over on-demand or persistent WAN links, such as analog phone, ISDN, or Point-to-Point Tunneling Protocol (PPTP)

  • Internet Control Message Protocol (ICMP) router discovery

  • Remote Authentication Dial-In User Service (RADIUS) client

  • IP and IPX packet filtering

  • PPTP support for router-to-router VPN connections

  • Routing and RAS Admin administrative tool and the Routemon command-line utility

The following features were provided by Windows 2000:

  • Multiprotocol Routing and Remote Access Service that can route IP, IPX, and AppleTalk simultaneously

  • Internet Group Management Protocol (IGMP) and support for multicast boundaries

  • Network Address Translation (NAT) that simplifies small office or home office (SOHO) network connections to the Internet through addressing and name resolution components

  • Layer 2 Tunneling Protocol (L2TP) over Internet Protocol Security (IPSec) support for router-to-router VPN connections and remote access

  • Demand-dial routing that can route IP and IPX over on-demand or persistent WAN links, such as analog phone lines, ISDN, or over VPN connections that use either PPTP or L2TP over IPSec

  • RRAS integration that provides the capability to integrate a firewall with RRAS and NAT functions

Windows Server 2003 continues the evolution of RRAS by adding some new features. Some of the Routing and Remote Access Service for Windows 2000 and Windows Server 2003 features include the following:

  • Point-to-Point Protocol over Ethernet (PPPoE) Dial-On-Demand

  • Background Intelligent Transfer Service (BITS)

  • NAT Traversal using Universal Plug and Play (UPnP)

  • Quarantine Policy Check

  • Improved administration and management tools that use a Microsoft Management Console (MMC) snap-in or the Netsh command-line tool

Point-to-Point Protocol Over Ethernet Dial-On-Demand

The PPPoE Dial-On-Demand feature provides the option to use Point-to-Point Protocol over Ethernet (PPPoE) in a dial-on-demand network connection, which enables the use of PPPoE with the RRAS NAT feature to connect to the Internet. PPPoE allows an RRAS server to connect to the Internet through a common broadband medium, such as a single DSL line, wireless device, or cable modem. All the users over the Ethernet share a common connection.

Background Intelligent Transfer Service Version 1.5

Background Intelligent Transfer Service (BITS) is a background file-transfer mechanism and queue manager. File transfers through BITS are throttled to help minimize the effect on the system's network performance while transferring large amounts of data. File transfer requests are also persistent across network disconnects and workstation reboots until the file transfer is complete. When the transfer is complete, the application that requested the file transfer is notified of the completion. This feature enables low-priority download operations to complete in the background without affecting users' bandwidth.

Version 1.5 of BITS adds down-level client support through redistribution, file upload support, and optional advanced upload features. Background File Upload requires the BITS server application, which is included in Windows Server 2003 and is available for redistribution for Windows 2000based servers.

NAT Traversal Using Universal Plug and Play

NAT Traversal technology was designed to enable network applications to detect the presence of a local NAT device. NAT Traversal provides a means for applications to create port mappings on local NAT devices such as Internet Connection Sharing (ICS) and other Internet gateway devices that support Universal Plug and Play (UPnP). The applications can identify the external IP address and automatically configure port mappings to forward packets from the external port of the NAT to the internal port used by the network application. Independent Software Vendors (ISVs) can use this feature to develop applications that create port mappings on UPnP-enabled NAT devices.

Quarantine Policy Check

Hidden in the Windows 2003 Resource Kit is an add-in utility called the Remote Quarantine Client. This tool provides administrators with the capability to check the status of remote systems for patch updates and virus scans, and quarantine the systems to be cleaned and updated before being allowed to access the network.

Quarantine Policy Check provides administrators with the tools necessary to minimize the risk of having viruses or worms inserted into a network by a remote access user by ensuring remote systems are up to date on the latest patches and updates.


Routing and Remote Access Service Architecture

Routing and Remote Access is built on a series of communications and management agents, transport protocols, forwarders, and APIs. These components have been built, expanded, and improved over the years to provide a secure, efficient, effective, and reliable communications system for client-to-server and server-to-server communications in a Windows networking environment.

Figure 26.1 diagrams the various components detailed through the balance of this section, noting each component and its role in the communications system.

Figure 26.1. The Routing and Remote Access Service.

SNMP Agent for RRAS

Windows Server 2003 RRAS supports the Simple Network Management Protocol (SNMP) management information bases (MIBs). The SNMP agent provides monitoring and alerting information for SNMP management systems. The SNMP agent is a critical component to the reliability and manageability of RRAS as a cornerstone to remote and mobile communications.

Management Applications

Management applications for RRAS include the Routing and Remote Access snap-in and the Netsh command-line utility. These applications are utilities that help an organization better administer the remote and mobile communications environment.

Authentication, Authorization, and Accounting

AAA is a set of components that provides authentication, authorization, and accounting for RRAS when it is configured for the Windows authentication provider or the Windows accounting provider. The local AAA components are not used when RRAS is configured for the RADIUS authentication or accounting provider. The AAA components are also used by the Internet Authentication Service (IAS).

Dynamic Interface Manager (Mprdim.dll)

The Dynamic Interface Manager component supports a Remote Procedure Call (RPC) interface for SNMP-based management functions used by management utilities such as the Routing and Remote Access snap-in. It communicates with the Connection Manager for demand-dial connections and configuration information to the router managers (such as the IP Router Manager and IPX Router Manager). The Dynamic Interface Manager also loads configuration information from the Windows Server 2003 Registry. In addition, it manages all routing interfaces, including local area network, persistent demand-dial, and IP-in-IP interfaces.

Connection Manager

The Connection Manager components manage WAN devices and establish connections by using TAPI. The Connection Manager also negotiates PPP control protocols, including Extensible Authentication Protocol (EAP) and also implements Multilink and Bandwidth Allocation Protocol (BAP).

Telephony Application Programming Interface

The Telephony Application Programming Interface (Telephony API or TAPI) provides services to create, monitor, and terminate connections independently of hardware. The Connection Manager uses TAPI to create or receive demand-dial connections.

IP Router Manager (Iprtmgr.dll)

The IP Router Manager component obtains configuration information from the Dynamic Interface Manager. It loads and communicates configuration information to IP routing protocols, such as RIP for IP and OSPF supplied with Windows Server 2003. It also communicates IP packet filtering configuration information to the IP filtering driver as well as communicates IP routing configuration information to the IP forwarder in the TCP/IP protocol. The IP Router Manager also maintains an interface database of all IP routing interfaces. In addition, it initiates demand-dial connections for routing protocols by communicating with the Dynamic Interface Manager.

IPX Router Manager (Ipxrtmgr.dll)

The IPX Router Manager obtains configuration information from the Dynamic Interface Manager and maintains an interface database of all IPX routing interfaces. It communicates IPX packet filtering configuration information to the IPX filtering driver as well as communicates IPX routing configuration information to the IPX forwarder driver. The IPX Router Manager loads and communicates configuration information to IPX routing protocols (RIP for IPX, SAP for IPX). In addition, it initiates demand-dial connections for routing protocols by communicating with the Dynamic Interface Manager.

Unicast Routing Protocols

RRAS provides the following four unicast routing protocols:

  • RIP for IP (Iprip2.dll) The RIP for IP routing protocol communicates RIP for IPlearned routes by using the Route Table Manager. It also uses Winsock to send and receive RIP for IP traffic and exports management APIs to support MIBs and management applications through the IP Router Manager.

  • OSPF Routing Protocol (Ospf.dll) The OSPF routing protocol communicates OSPF-learned routes by using the Route Table Manager. It uses Winsock to send and receive OSPF traffic as well as exports management APIs to support MIBs and management applications through the IP Router Manager.

  • RIP for IPX (ipxrip.dll) The RIP for IPX routing protocol communicates RIP for IPXlearned routes by using the Route Table Manager. It uses Winsock to send and receive RIP for IPX traffic. It also exports management APIs to support MIBs and management applications through the IPX Router Manager.

  • SAP for IPX (ipxsap.dll) The SAP for IPX routing protocol communicates SAP for IPXlearned routes by using the Route Table Manager. It uses Winsock to send and receive SAP for IPX traffic and also exports management APIs to support MIBs and management applications through the IPX Router Manager.

IP Multicast Routing Protocols

The IP multicast routing protocol that RRAS uses is IGMP (versions 1, 2, and 3). IGMP communicates multicast group membership information to the Multicast Group Manager. It also uses Winsock to send and receive IGMP traffic and exports management APIs to support MIBs and management applications through the Multicast Group Manager.

Route Table Manager (Rtm.dll)

The Route Table Manager maintains a user-mode route table for all routes from all possible route sources. It displays APIs for adding, deleting, and enumerating routes that are used by the routing protocols. The Route Table Manager also communicates only the best routes to the appropriate forwarder driver. The best routes are those that have the lowest preference level (for IP routes) and the lowest metrics. The best routes become the routes in the IP forwarding table and IPX forwarding table.

Multicast Group Manager

The Multicast Group Manager maintains all multicast group memberships and communicates multicast forwarding entries (MFEs) in the IP Multicast Forwarder. It also reflects group membership between IP multicast routing protocols.

IP Filtering Driver (Ipfltdrv.sys)

The IP filtering driver obtains configuration information from the IP Router Manager. It also applies IP filters after the IP forwarder has found a route.

IP Unicast Forwarder

The IP Unicast Forwarder, a component of the TCP/IP protocol (Tcpip.sys), obtains configuration information from the IP Router Manager. It stores the IP forwarding table, a table of the best routes obtained from the Route Table Manager. It can also initiate a demand-dial connection and forward unicast IP traffic.

IP Multicast Forwarder

The IP Multicast Forwarder, which is a component of the TCP/IP protocol (Tcpip.sys), stores multicast forward entries obtained from IP multicast routing protocols through the Multicast Group Manager. It is based on multicast traffic received and communicates new source or group information to the Multicast Group Manager. It also forwards IP multicast packets.

IPX Filtering Driver (Nwlnkflt.sys)

The IPX filtering driver obtains configuration information from the IPX Router Manager and applies IPX filters after the IPX forwarder driver has found a route.

IPX Forwarder Driver (Nwlnkfwd.sys)

The IPX forwarder driver obtains configuration information from the IPX Router Manager and also stores the IPX forwarding table, a table of the best routes obtained from the Route Table Manager. The IPX forwarder driver can initiate a demand-dial connection as well as forward IPX traffic.


Virtual Private Networking in Windows 2003

A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. A VPN allows data to be sent between two computers across the Internet in a manner that emulates a point-to-point private link. With a virtual private network, illustrated in Figure 26.2, a point-to-point link, or tunnel, is created by encapsulating or wrapping the data with a header that provides routing information that allows the data to travel through the Internet. A private link is created by encrypting the data for confidentiality; data packets that are intercepted while traveling through the Internet are unreadable without the proper encryption keys.

Figure 26.2. Virtual private networking across the Internet.

VPN technology provides corporations with a scalable and low-cost solution for remote access to corporate resources. VPN connections allow remote users to securely connect to their corporate networks across the Internet. Remote users would access resources as if they were physically connected to the corporate LAN.

Components Needed to Create a VPN Connection

A virtual private network connection requires a VPN client and a VPN server. A secured connection is created between the client and server through encryption that establishes a tunnel, as shown in Figure 26.3.

Figure 26.3. Establishing a VPN tunnel between a client and server.

The VPN Client

A VPN client is a computer that initiates a VPN connection to a VPN server. It can be a remote computer that establishes a VPN connection or a router that establishes a router-to-router VPN connection. Microsoft clients including Windows NT 4.0, Windows 9x, Windows 2000, and Windows XP can create a remote access VPN connection to a Windows Server 2003 system.

Windows NT Server 4.0, Windows 2000 Server, and Windows Server 2003based computers running RRAS can create router-to-router VPN connections to a Windows Server 2003 VPN server. VPN clients can also be any non-Microsoft PPTP client or L2TP client using IPSec.

The VPN Server

A VPN server is a computer that accepts VPN connections from VPN clients. It can provide a remote access VPN connection or a router-to-router VPN connection. The VPN server name or IP address must be resolvable as well as accessible through corporate firewalls.

Tunnel/VPN Connection

The tunnel is the portion of the connection in which data is encapsulated. The VPN connection is the portion of the connection where the data is encrypted. The data encapsulation, along with the encryption, provides a secure VPN connection.

Note

A tunnel that is created without the encryption is not a VPN connection because the private data is sent across the Internet unencrypted and can be easily read.

Internet/Intranet Infrastructure

A shared or public internetwork is required to establish a VPN connection. For Windows Server 2003, the transit internetwork is always an IP-based network that includes the Internet as well as a corporation's private IP-based intranet.


Authentication Options to an RRAS System

Authentication in any networking environment is critical for validating whether the individual wanting access should be allowed access to network resources. Authentication is an important component in the Windows Server 2003 security initiative. Windows Server 2003 can authenticate a remote access user connection through a variety of PPP authentication protocols, including

  • Password Authentication Protocol (PAP)

  • Challenge-Handshake Authentication Protocol (CHAP)

  • Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

  • MS-CHAP version 2 (MS-CHAP v2)

  • Extensible Authentication Protocol-Message Digest 5 (EAP-MD5)

  • Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)

Authentication Protocols for PPTP Connections

For PPTP connections, only three authentication protocols (MS-CHAP, MS-CHAP v2, and EAP-TLS) provide a mechanism to generate the same encryption key on both the VPN client and VPN server. Microsoft Point-to-Point Encryption (MPPE) uses this encryption key to encrypt all PPTP data sent on the VPN connection. MS-CHAP and MS-CHAP v2 are password-based authentication protocols.

Without a Certificate Authority (CA) server or smartcards, MS-CHAP v2 is highly recommended because it provides a stronger authentication protocol than MS-CHAP. MS-CHAP v2 also provides mutual authentication, which allows the VPN client to be authenticated by the VPN server and the VPN server to be authenticated by the VPN client.

If a password-based authentication protocol must be used, it is good practice to enforce the use of strong passwords (passwords greater than eight characters) that contain a random mixture of upper and lowercase letters, numbers, and punctuation. Group Policies can be used in Active Directory to enforce strong user passwords.

EAP-TLS Authentication Protocols

Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) is designed to be used along with a certificate infrastructure that uses user certificates or smartcards. With EAP-TLS, the VPN client sends its user certificate for authentication, and the VPN server sends a computer certificate for authentication. This is the strongest authentication method because it does not rely on passwords. Third-party CAs can be used as long as the certificate in the computer store of the IAS server contains the Server Authentication certificate purpose (also known as a certificate usage or certificate issuance policy). A certificate purpose is identified using an object identifier (OID). If the OID for Server Authentication is 1.3.6.1.5.5.7.3.1, the user certificate installed on the Windows 2000 remote access client must contain the Client Authentication certificate purpose (OID 1.3.6.1.5.5.7.3.2).

Authentication Protocols for L2TP/IPSec Connections

For L2TP/IPSec connections, any authentication protocol can be used because the authentication occurs after the VPN client and VPN server have established a secure connection known as an IPSec security association (SA). The use of either MS-CHAP v2 or EAP-TLS is recommended to provide strong user authentication.

Choosing the Best Authentication Protocol

Organizations spend very little time choosing the most appropriate authentication protocol to use with their VPN connections. In many cases, the lack of knowledge about the differences between the various authentication protocols is the reason a selection is not made. In other cases, the desire for simplicity is the reason heightened security is not chosen as part of the organization's authentication protocol decisions. Whatever the case, we make the following suggestions to assist you in selecting the best authentication protocol for VPN connections:

  • Using the EAP-TLS authentication protocol for both PPTP and L2TP connections is highly recommended if the following conditions exist in an organization. If a smartcard will be used, or if a certificate infrastructure that issues user certificates exists, then EAP-TLS is the best and most secure option. Note that EAP-TLS is supported only by VPN clients running Windows XP and Windows 2000.

  • Use MS-CHAP v2 and enforce strong passwords using group policy if you must use a password-based authentication protocol. Although not as strong of a security protocol as EAP-TLS, MS-CHAP v2 is supported by computers running Windows XP, Windows 2000, Windows NT 4.0 with Service Pack 4 and higher, Windows Me, Windows 98, and Windows 95 with the Windows Dial-Up Networking 1.3 or higher Performance and Security Update.


VPN Protocols

PPTP and L2TP are the communication standards used to manage tunnels and encapsulate private data. It is important to note that data traveling through a tunnel must also be encrypted to be a VPN connection. Windows Server 2003 includes both PPTP and L2TP tunneling protocols.

To establish a tunnel, both the tunnel client and tunnel server must be using the same tunneling protocol. Tunneling technology can be based on either a Layer 2 or Layer 3 tunneling protocol that corresponds to the Open System Interconnection (OSI) Reference Model. Layer 2 protocols correspond to the Data-link layer and use frames as their unit of exchange. PPTP and L2TP are Layer 2 tunneling protocols that encapsulate the payload in a PPP frame before it is sent across the Internet. Layer 3 protocols correspond to the Network layer and use packets. IPSec tunnel mode is a Layer 3 tunneling protocol that encapsulates IP packets in an additional IP header before sending them across the Internet.

Tunneling Within a Windows Server 2003 Networking Environment

For Layer 2 tunneling technologies, such as PPTP and L2TP, a tunnel is similar to a session; both of the tunnel endpoints must agree to the tunnel and must negotiate configuration variables, such as address assignment or encryption or compression parameters. In most cases, data transferred across the tunnel is sent using a datagram-based protocol. A tunnel maintenance protocol is used as the mechanism to manage the tunnel. Layer 3 tunneling technologies generally assume that all the configuration settings are preconfigured, often by manual processes. For these protocols, there may be no tunnel maintenance phase. For Layer 2 protocols (PPTP and L2TP), however, a tunnel must be created, maintained, and then terminated.

After the tunnel is established, tunneled data can be sent. The tunnel client or server uses a tunnel data transfer protocol to prepare the data for transfer. For example, as illustrated in Figure 26.4, when the tunnel client sends a payload to the tunnel server, the tunnel client first appends a tunnel data transfer protocol header to the payload. The client then sends the resulting encapsulated payload across the internetwork, which routes it to the tunnel server. The tunnel server accepts the packets, removes the tunnel data transfer protocol header, and forwards the payload to the target network. Information sent between the tunnel server and tunnel client behaves similarly.

Figure 26.4. Tunneling payload through a VPN connection.

Point-to-Point Tunneling Protocol

The Point-to-Point Tunneling Protocol (PPTP) is a Layer 2 protocol that encapsulates PPP frames in IP datagrams for transmission over the Internet. PPTP can be used for remote access and router-to-router VPN connections. It uses a TCP connection for tunnel maintenance and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted and/or compressed. Figure 26.5 shows the structure of a PPTP packet containing user data.

Figure 26.5. Structure of the PPTP packet.

Layer 2 Tunneling Protocol

Layer 2 Tunneling Protocol (L2TP) is a combination of the Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Forwarding (L2F), a technology proposed by Cisco Systems, Inc. L2TP encapsulates PPP frames that are sent over IP, X.25, frame relay, and ATM networks. The payloads of encapsulated PPP frames can be encrypted and/or compressed. When sent over the Internet, L2TP frames are encapsulated as User Datagram Protocol (UDP) messages, as shown in Figure 26.6.

Figure 26.6. Structure of the L2TP packet.

L2TP frames include L2TP connection maintenance messages and tunneled data. L2TP connection maintenance messages include only the L2TP header. L2TP tunneled data includes a PPP header and PPP payload. The PPP payload can be encrypted or compressed (or both) using standard PPP encryption and compression methods.

In Windows Server 2003, L2TP connections do not negotiate the use of PPP encryption through Microsoft Point-to-Point Encryption (MPPE). Instead, encryption is provided through the use of the IP Security (IPSec) Encapsulating Security Payload (ESP) header and trailer.

IP Security

IP Security (IPSec) was designed as an end-to-end mechanism for ensuring data security in IP-based communications. Illustrated in Figure 26.7, the IPSec architecture includes an authentication header to verify data integrity and an encapsulation security payload for both data integrity and data encryption. IPSec provides two important functions that ensure confidentiality: data encryption and data integrity. IPSec uses an authentication header (AH) to provide source authentication and integrity without encryption and the Encapsulating Security Payload (ESP) to provide authentication and integrity along with encryption. With IPSec, only the sender and recipient know the security key. If the authentication data is valid, the recipient knows that the communication came from the sender and that it was not changed in transit.

Figure 26.7. Structure and architecture of the IPSec packet.

Previous Page
Next Page


Choosing Between PPTP and L2TP/IPSec

One of the choices to make when you're deploying Windows Server 2003based VPNs is whether to use L2TP/IPSec or PPTP. Windows XP and Windows 2000 VPN client and server computers support both L2TP/IPSec and PPTP by default. Both PPTP and L2TP/IPSec use PPP to provide an initial envelope for the data and then append additional headers for transport through the Internet. PPTP and L2TP also provide a logical transport mechanism to send PPP payloads and provide tunneling or encapsulation so that PPP payloads based on any protocol can be sent across the Internet. PPTP and L2TP rely on the PPP connection process to perform user authentication and protocol configuration.

There are a few differences between the PPTP and L2TP protocols. First, when using PPTP, the data encryption begins after the PPP connection process is completed, which means PPP authentication is used. With L2TP/IPSec, data encryption begins before the PPP connection process by negotiating an IPSec security association. Second, PPTP connections use MPPE, a stream cipher that is based on the Rivest-Shamir-Aldeman (RSA) RC-4 encryption algorithm and uses 40-, 56-, or 128-bit encryption keys. Stream ciphers encrypt data as a bit stream. L2TP/IPSec connections use the Data Encryption Standard (DES), which is a block cipher that uses either a 56-bit key for DES or three 56-bit keys for 3-DES. Block ciphers encrypt data in discrete blocks (64-bit blocks, in the case of DES). Finally, PPTP connections require only user-level authentication through a PPP-based authentication protocol. L2TP/IPSec connections require the same user-level authentication as well as computer-level authentication using computer certificates.

Advantages of L2TP/IPSec Over PPTP

Although PPTP users significantly outnumber L2TP/IPSec users, because of a higher level of security in L2TP/IPSec as well as several other benefits of L2TP/IPSec, organizations that are seeking to improve secured remote connectivity are beginning to implement L2TP/IPSec VPN as their remote and mobile access standard. The following are the advantages of using L2TP/IPSec over PPTP:

  • IPSec provides per packet data authentication (proof that the data was sent by the authorized user), data integrity (proof that the data was not modified in transit), replay protection (prevention from resending a stream of captured packets), and data confidentiality (prevention from interpreting captured packets without the encryption key). PPTP provides only per-packet data confidentiality.

  • L2TP/IPSec connections provide stronger authentication by requiring both computer-level authentication through certificates and user-level authentication through a PPP authentication protocol.

  • PPP packets exchanged during user-level authentication are never sent unencrypted because the PPP connection process for L2TP/IPSec occurs after the IPSec security associations are established. If intercepted, the PPP authentication exchange for some types of PPP authentication protocols can be used to perform offline dictionary attacks and determine user passwords. If the PPP authentication exchange is encrypted, offline dictionary attacks are possible only after the encrypted packets have been successfully decrypted.

Advantages of PPTP Over L2TP/IPSec

Although L2TP/IPSec is perceived to be more secure than a PPTP VPN session, there are significant reasons organizations choose PPTP over L2TP/IPSec. The following are advantages of PPTP over L2TP/IPSec:

  • PPTP does not require a certificate infrastructure. L2TP/IPSec requires a certificate infrastructure for issuing computer certificates to the VPN server computer (or other authenticating server) and all VPN client computers.

  • PPTP can be used by all Windows desktop platforms (Windows XP, Windows 2000, Windows NT 4.0, Windows Millennium Edition (Me), Windows 98, and Windows 95 with the Windows Dial-Up Networking 1.3 Performance and Security Update). Windows XP and Windows 2000 VPN clients are the only clients that support L2TP/IPSec and the use of certificates.

IPSec functions at a layer below the TCP/IP stack. This layer is controlled by a security policy on each computer and a negotiated security association between the sender and receiver. The policy consists of a set of filters and associated security behaviors. If a packet's IP address, protocol, and port number match a filter, the packet is subject to the associated security behavior.


Installing and Configuring Routing and Remote Access

Unlike with most network services of Windows Server 2003, RRAS cannot be installed or uninstalled through the Add or Remove Programs applet in the Control Panel. After you install Windows Server 2003, Routing and Remote Access is automatically installed in a disabled state.

To enable and configure the Routing and Remote Access Service, log on using an account that has local administrator privileges. Then follow these steps:

1.
Choose Start, Programs, Administrative Tools, Routing and Remote Access, as shown in Figure 26.8.

Figure 26.8. Launching the Routing and Remote Access administration tool.

[View full size image]

2.
For the local computer, right-click the server icon and select Configure and Enable Routing and Remote Access, as shown in Figure 26.9.

Figure 26.9. Configuring and enabling Routing and Remote Access.

[View full size image]

3.
For a remote computer, right-click the Server Status icon and click Add Server. In the Add Server property page, select the server you want to add. Then right-click the remote server icon and select Configure and Enable Routing and Remote Access.

4.
Press Next on the Routing and Remote Access Setup Wizard Welcome page to continue.

5.
Select the custom configuration option and then click Next.

6.
Choose the options you want to configure in the Routing and Remote Access Server Setup Wizard, as shown in Figure 26.10.

Figure 26.10. Choosing installation options in the Routing and Remote Access Server Setup Wizard.

[View full size image]

7.
After you complete the wizard steps, the remote access router is enabled and configured based on your selections in the wizard. To configure additional features, use the Routing and Remote Access snap-in.


Configuring Remote Access Clients

In a remote access networking environment, the server component is only half of the configuration, and the remote access clients need to be properly configured to complete the secured mobile access environment. There are many variations in remote access client systems that make choosing the right client configuration important.

A client system could vary based on the operating system such as Windows 95/98, Windows NT4, Windows 2000, or Windows XP, or the client system could be Macintosh, Unix, or even a system at an Internet café or kiosk in an airport. The configuration of the client system also varies based on the type of information being transferred, such as just email, or the transmission of files or confidential database information.

This section covers the technologies available and the decisions that need to be made to choose the right configuration for remote access client systems.

VPN Client Configuration

If you have a small number of VPN clients, you can configure the connections manually for each client. For an environment with a hundred or more remote access VPN clients, it makes more sense to configure the remote access configuration automatically. Some of the problems encountered when automatically configuring VPN connections for a large environment include the following:

  • The organization has a variety of Windows desktop clients.

  • End users make configuration errors.

  • A VPN connection may need a double-dial configuration, where a user must dial the Internet first before creating a VPN connection with the organization's intranet.

The solution to these configuration issues is to use the Connection Manager, which contains the following features:

  • Connection Manager Client Dialer

  • Connection Manager Administration Kit

  • Connection Point Services

Connection Manager Client Dialer

The Connection Manager (CM) client dialer is software that is installed on each remote access client. It includes advanced features that make it a superset of basic dial-up networking. CM simplifies the client configuration for the users by enabling them to do the following:

  • Select from a list of phone numbers to use, based on physical location.

  • Use customized graphics, icons, messages, and help.

  • Automatically create a dial-up connection before the VPN connection is made.

  • Run custom actions during various parts of the connection process, such as pre-connect and post-connect actions.

A customized CM client dialer package (CM profile) is a self-extracting executable file created by the Connection Manager Administration Kit. The CM profile can be distributed to VPN users via CD-ROM, email, Web site, or file share. The CM profile automatically configures the appropriate dial-up and VPN connections. The Connection Manager profile does not require a specific version of Windows and will run on the following platforms: Windows XP, Windows 2000, Windows NT 4.0, Windows Millennium Edition, and Windows 98.

Connection Manager Administration Kit

The Connection Manager Administration Kit (CMAK) allows administrators to preconfigure the appearance and behavior of the CM. With CMAK, client dialer and connection software allows users to connect to the network using only the connection features that are defined for them. CMAK also allows administrators to build profiles customizing the Connection Manager Installation package sent to remote access users.

Connection Point Services

Connection Point Services (CPS) allows the automatic distribution and update of custom phone books. These phone books contain one or more Point of Presence (POP) entries, with each POP containing a telephone number that provides dial-up access information for an Internet access point. The phone books give users a complete POP list, which enables remote users to connect to different Internet access points when they travel. CPS also can automatically update the phone book when changes are made to the POP list.

CPS has two components:

  • Phone Book Administrator A tool used to create and maintain the phone book database and to publish new phone book information to the Phone Book Service.

  • Phone Book Service A Microsoft Internet Information Services (IIS) extension that runs on a Windows Server 2003 server configured with IIS. Phone Book Service automatically checks the current phone book and downloads a phone book update if required.

The Connection Manager Administration Kit (CMAK) and the Connection Point Service (CPS) are not installed by default on a Windows Server 2003 system. To install the CMAK and CPS, do the following:

1. | Click on Start, Control Panel, Add or Remove Programs.
2. | Click on Add/Remote Windows Components.
3. | On the Windows Components Wizard screen, double-click Management and Monitoring Tools.
4. | Select Connection Manager Administration Kit and Connection Point Service.
5. | Click OK and then click Next to complete the installation of the components. Click Finished when done.

Single Sign-on

Single sign-on enables remote access users to create a remote access connection to an organization and log on to the organization's domain by using the same set of credentials. For a Windows Active Directory domain-based infrastructure, the username and password or a smartcard is used for both authenticating and authorizing a remote access connection and for authenticating and logging on to a Windows domain. You enable single sign-on by selecting the Logon by Using Dial-Up Networking option on the Windows XP and Windows 2000 logon property page and then selecting a dial-up or VPN connection to connect to the organization. For VPN connections, the user must first connect to the Internet before creating a VPN connection. After the Internet connection is made, the VPN connection and logon to the domain can be established.

The Impact of NAT Traversal at Improving Remote Connectivity

Network Address Translation Traversal (NAT-T) is a set of capabilities that allows network-aware applications to discover they are behind a NAT device, learn the external IP address, and configure port mappings to forward packets from the external port of the NAT to the internal port used by the application. This process happens automatically, so the user does not have to manually configure port mappings. NAT Traversal relies on discovery and control protocols that are part of the Universal Plug and Play Forumdefined specifications. The UPnP Forum has a working committee focused on defining the control protocol for Internet gateway devices and defining the services for these devices. NAT and NAT Traversal will no longer be needed in an IPv6 world where every client has a globally routable IP address.

The significance of NAT Traversal is the ability of a privately addressed L2TP/IPSec client to access an RRAS system. In Windows 2000, although L2TP/IPSec was introduced, it was rarely used for remote users because individuals who connect to the Internet frequently connect through a private address public provider using NAT. As an example, when a user connects to the Internet from a hotel, airport, wireless Internet café connection, or the like, the host provider of Internet connectivity usually does not issue a public IP address. Rather the provider uses Network Address Translation, effectively providing the user a private 10.x.x.x address behind a proxy. With Windows 2000, the L2TP/IPSec client cannot traverse out of the private address space.

With Windows Server 2003, NAT Traversal allows the privately addressed L2TP/IPSec client to route outside the private address zone, thus allowing the client to gain VPN connectivity. In early implementations of Windows Server 2003, many organizations have migrated to this new OS specifically for the benefit of being able to set up a NAT Traversal RRAS system.


RRAS Tools and Utilities

Several tools and utilities are available for Windows Server 2003 Routing and Remote Access Service. The following utilities allow administrators to configure and obtain information for accounting, auditing, and troubleshooting RRAS:

  • Routing and Remote Access MMC snap-in

  • Netsh command-line tool

  • Authentication and accounting logging

  • Event logging

  • Tracing

Routing and Remote Access MMC Snap-in

The Routing and Remote Access snap-in, shown in Figure 26.11, is located in the Administrative Tools folder. It is the primary management tool for configuring Windows Server 2003 RRAS.

Figure 26.11. Administering RRAS through the Routing and Remote Access snap-in.

[View full size image]

Within the RRAS snap-in is a series of floating windows that display table entries or statistics. After a floating window is displayed, you can move it anywhere on the screen, and it remains on top of the Routing and Remote Access snap-in. Table 26.1 lists the floating windows in the Routing and Remote Access snap-in and includes their location.

Table 26.1. Routing and Remote Access Floating Windows

Floating Window

Location

Description

TCP/IP information

IP Routing/General/Interface

Global TCP/IP statistics, such as the number of routes, incoming and outgoing bytes

Multicast boundaries

IP Routing/General/Interface

The contents of the TCP/IP multicast boundaries

Multicast statistics

IP Routing/General

Statistics per group, such as the number of multicast packets received

Address translations

IP Routing/General/Interface

The contents of the Address Resolution Protocol (ARP) cache

IP addresses

IP Routing/General/Interface

The IP addresses assigned to routing interfaces

IP routing table

IP Routing/General/Static Routes

The contents of the IP routing table

RRAS Clients

Remote Access Clients

The list of client connections, including local and remote addresses and TCP ports

UDP listener ports

Ports

The list of UDP ports on which the router is listening

Areas

IP Routing/OSPF

The list of configured OSPF areas

Link state database

IP Routing/OSPF

The contents of the OSPF link state database

Neighbors (OSPF)

IP Routing/OSPF

The list of neighboring OSPF routers and their state

Virtual interfaces

IP Routing/OSPF

The list of configured virtual interfaces and their state

Neighbors (RIP)

IP Routing/RIP

The list of neighboring RIP routers

DHCP Allocator information

IP Routing/NAT/Basic Firewall

Statistics on the number and types of DHCP messages sent and received

DNS Proxy information

IP Routing/Network Address Translation

Statistics on the number of types of DNS messages sent and received

Mappings

IP Routing/NAT/Basic Firewall/Interface

Contents of the Network Address Translation mapping table

Group table

IP Routing/IGMP

Global list of groups detected by using the IGMP routing protocol

Interface group table

IP Routing/IGMP/Interface

Interface list of groups detected by using the IGMP routing protocol

IPX parameters

IPX Routing/General

Global IPX statistics, such as the number of routes and services, packets received, and packets forwarded

IPX routing table

IPX Routing/Static Routes

The contents of the IPX routing table

IPX service table

IPX Routing/Static Services

The contents of the SAP service table

RIP parameters

IPX Routing/RIP for IPX

Global statistics on the RIP for IPX protocol

SAP parameters

IPX Routing/SAP for IPX

Global statistics on the SAP for IPX protocol

The Netsh Command-Line Tool

Netsh is a command-line and scripting tool used to configure Windows Server 2003 networking components on local or remote computers. Windows Server 2003 Netsh also enables you to save a configuration script in a text file for archiving or for configuring other servers. Netsh is installed with the Windows Server 2003 operating system.

Netsh is a shell that can support multiple Windows Server 2003 components through the addition of Netsh helper DLLs. A Netsh helper DLL extends Netsh functionality by providing additional commands to monitor or configure a specific Windows Server 2003 networking component. Each Netsh helper DLL provides a context or group of commands for a specific networking component. Subcontexts can exist within each context; for example, within the routing context, the subcontexts IP and IPX exist to group IP routing and IPX routing commands together.

Netsh command-line options include the following:

  • a <AliasFile> Specifies that an alias file be used. An alias file contains a list of Netsh commands and an aliased version so that the aliased command line can be used in place of the Netsh command. Alias files can be used to map commands to the appropriate Netsh command that might be more familiar in other platforms.

  • c <Context> Specifies the context of the command corresponding to an installed helper DLL.

  • Command Specifies the Netsh command to carry out.

  • f <ScriptFile> Specifies that all the Netsh commands in the file ScriptFile be run.

  • r <Remote Computer Name or IP Address> Specifies that Netsh commands are run on the remote computer specified by its name or IP address.

You can abbreviate Netsh commands to the shortest unambiguous string. For example, typing the command ro ip sh int is equivalent to typing routing ip show interface. Netsh commands can be either global or context specific. You can issue global commands in any context and use them for general Netsh functions. Context-specific commands vary according to the context. Table 26.2 lists the global commands for Netsh.

Table 26.2. Netsh Commands

Command

Description

..

Moves up one context level.

? or help

Displays command-line Help.

show version

Displays the current version of Windows and the Netsh utility.

show netdlls

Displays the current version of installed Netsh helper DLLs.

add helper

Adds a Netsh helper DLL.

delete helper

Removes a Netsh helper DLL.

show helper

Displays the installed Netsh helper DLLs.

cmd

Creates a command window.

online

Sets the current mode to online.

offline

Sets the current mode to offline.

set mode

Sets the current mode to online or offline.

show mode

Displays the current mode.

flush

Discards any changes in offline mode.

commit

Commits changes made in offline mode.

set audit-logging

Turns on or off the logging facility.

show audit-logging

Displays current audit logging settings.

set loglevel

Sets level of logging information.

show loglevel

Displays the level of logging information.

set machine

Configures the computer on which the Netsh commands are executed.

show machine

Displays the computer on which the Netsh commands are executed.

exec

Executes a script file containing Netsh commands.

quit or bye or exit

Exits the Netsh utility.

add alias

Adds an alias to an existing command.

delete alias

Deletes an alias to an existing command.

show alias

Displays all defined aliases.

dump

Writes configuration to a text file.

popd

A scripting command that pops a context from the stack.

pushd

A scripting command that pushes the current context on the stack.

Netsh can function in two modes: Online and Offline. In Online mode, commands executed by Netsh are carried out immediately. In Offline mode, commands executed at the Netsh prompt are accumulated and carried out as a batch by using the commit global command. The flush global command discards the batch commands. Netsh commands can also run through a script. You can run the script by using the f option or by executing the exec global command at the Netsh command prompt.

The dump command can be used to generate a script that captures the current RRAS configuration. This command generates the current running configuration in terms of Netsh commands. The generated script can be used to configure a new RRAS server or modify the current one.

For the Routing and Remote Access Service, Netsh has the following contexts:

  • ras Use commands in the ras context to configure remote access configuration.

  • aaa Use commands in the aaa context to configure the AAA component used by both Routing and Remote Access Service and Internet Authentication Service.

  • routing Use commands in the routing context to configure IP and IPX routing.

  • interface Use commands in the interface context to configure demand-dial interfaces.

Authentication and Accounting Logging

The Routing and Remote Access Service can log authentication and accounting information for PPP-based connection attempts. This logging is separate from the events found in the system event log and can assist in tracking remote access usage and authentication attempts. Authentication and accounting logging is useful for troubleshooting remote access policy issues; the result of each authentication attempt is recorded, as is the remote access policy that was applied. The authentication and accounting information is stored in a configurable log file or in files stored in the %systemroot%\System32\LogFiles folder. The log files are saved in Internet Authentication Service (IAS) or in database-compatible format, which can allow database programs to read the log file directly for analysis. Logging can be configured for the type of activity you want to log (accounting or authentication activity). The log file settings can be configured from the properties of the Local File object in the Remote Access Logging folder in the Routing and Remote Access snap-in.

Event Logging

Windows Server 2003 RRAS also performs extensive error logging in the system event log. You can use information in the event logs to troubleshoot routing or remote access problems.

The following four levels of logging are available:

  • Log errors only (the default)

  • Log errors and warnings

  • Log the maximum amount of information

  • Disable event logging

You can set the level of event logging on the General tab of the following property pages:

  • IP Routing/General

  • IP Routing/NAT/Basic Firewall

  • IP Routing/OSPF

  • IP Routing/IGMP

  • IPX Routing/General

  • Routing/RIP for IPX

  • IPX Routing/SAP for IPX

Note

Logging uses system resources; therefore, you should use it sparingly to help identify network problems. After you identify the problem, reset the logging to its default setting (log errors only).

Tracing

RRAS for Windows Server 2003 provides extensive tracing capability that can be used to troubleshoot complex network problems. By enabling file tracing, you can record internal component variables, function calls, and interactions. File tracing can be enabled on various RRAS components to log tracing information to files. Enabling file tracing requires changing settings in the Windows Server 2003 Registry.

Caution

Do not edit the Registry unless you have no alternative. The Registry Editor bypasses standard safeguards, allowing settings that can damage your system or even require you to reinstall Windows.

Each installed routing protocol or component is capable of tracing, and each appears as a subkey, such as OSPF and RIPV2.

Similar to the authentication and accounting logging, tracing consumes system resources; therefore, you should use it sparingly to help identify network problems. After the trace is complete or the problem is identified, immediately disable tracing. Do not leave tracing enabled on multiprocessor computers.

The tracing information can be complex and detailed. Often, this information is useful only to Microsoft support engineers or network administrators who are experts in using the Windows Server 2003 Routing and Remote Access service. To enable file tracing for each component, do the following:

1. | Run regedit.exe and navigate to the following Registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\<Component> (<Component> represents the component for which you want to enable file tracing.)
2. | Select the component for which you want to enable file tracing.
3. | Right-click the EnableFileTracing entry, click Modify, and then assign a value of 1 (the default value is 0).
4. | For the selected component, modify additional entries as needed:

To set the location of the trace file, right-click the FileDirectory entry, click Modify, and then type the location of the log file as a path. The filename for the log file is the name of the component for which tracing is enabled. By default, log files are placed in the %windir%\Tracing directory.

To set the level of file tracing, right-click the FileTracingMask entry, click Modify, and then type a value for the tracing level. The tracing level can be from 0 to 0xFFFF0000. By default, the level of file tracing is set to 0xFFFF0000, which is the maximum level of tracing.

To set the maximum size of a log file, right-click the MaxFileSize entry, click Modify, and then type a size for the log file. The default value is 0x00100000, or 64KB.


Leveraging the Capabilities of the Quarantine Policy Check Tool

The most significant tool in the Windows 2003 Resource Kit for remote access environments is the Quarantine Policy Check add-in. This is one of those hidden gems buried in the Resource Kit that would otherwise be overlooked if not brought to your attention. The Quarantine Policy Check tool enables an administrator to stop a VPN user from directly accessing a network by first checking to make sure the user's system meets minimum network requirements before accessing the network. The policy check can confirm whether the remote system has the latest security patches applied, or that the system has been recently scanned for viruses and worms. If the system fails the validation, the system is quarantined and an additional policy can be initiated to conduct the appropriate patch updates and virus scan and cleaning before the remote system is connected to the production network. If the system passes the policy check, the remote user system is allowed connection to the network.

How the Quarantine Policy Check Works

The Quarantine Policy Check works in conjunction with the Connection Manager and is a post-connection action that initiates a network policy script immediately after a remote user properly authenticates into the network, but before the user is actually connected to the production network. The network policy script performs a validation check on the remote access client system to verify that the system conforms to the security policies for patch updates and virus-clean requirements of the organization. When the script has run successfully and the remote system has satisfied the requirements of the network policy, the system is allowed access to the network. If the script fails, the remote access user is denied access to the production network and is commonly redirected to an organization Web page that describes how users can make their systems comply with organizational policies. This may include redirecting the user to a script that performs the appropriate updates and virus-scan cleans necessary to get the remote system updated for a subsequent logon attempt to the production network.

The various files in the Windows 2003 Resource kit for the Quarantine Policy Check tool are rqc.exe, rqs.exe, and rqs_setup.bat. After RRAS is up and running on a Windows 2003 server for VPN and/or dial-up client access use, an administrator can run the rqs_setup batch file that "installs" the rqs server agent. The rqc agent is installed on remote systems and acts as the remote administrative control component for the quarantine check and validation processes.

Quarantine Control Components and System Requirements

To be able to use the Quarantine Policy Check tools, a network should be running Windows Active Directory so that group policies can be enabled to manage the quarantine checks. Although it is possible to put a Windows 2003 RRAS server on a Windows NT4 domain and use system policies to enable the Quarantine Policy Check functionality, for the purpose of this Windows 2003-focused book, it is assumed that the organization already has Active Directory enabled in the environment and that all policies will be group policies in Active Directory.

The components needed to enable Quarantine Policy Check include the following:

  • Windows Active Directory Environment (so that group policies can be used for quarantine policy checks)

  • Windows 2003 Routing and Remote Access (RRAS) Server

  • Quarantine Policy Check policies created and enabled

  • Quarantine-compatible RADIUS server (optional)

  • Quarantine-compatible remote access clients

The remote access clients that are supported for the Quarantine Policy Check include the following:

  • Windows Server 2003 systems

  • Windows Server 2000 systems

  • Windows XP Professional workstations

  • Windows 2000 Professional workstations

  • Windows Millennium edition and Windows 98 Second Edition workstations (with limitations)

Note

Although Windows Millennium and Windows 98 Second Edition systems are supported by the Quarantine Policy Check client tool, because these editions of Windows do not support Windows 2003 group policies, the quarantine policies cannot be enforced on these systems. Without the ability of forcing policies, the full benefits of Quarantine Policy Check enforcement are greatly limited. It is recommended that remote client systems use Windows 2000 or XP Professional, or Windows 2000/2003 Server at a minimum.

Installing the RQS.EXE Utility on an RRAS Server

To get the Quarantine Policy Check working, download and install the Windows 2003 Resource Kit on the Windows 2003 server that will be the RRAS server for the organization. The Windows 2003 Resource Kit can be downloaded at http://www.microsoft.com/windowsserver2003/downloads/default.mspx.

After the Resource Kit has been installed, three files will be needed to run the Quarantine Policy Check: RQS.EXE, RQC.EXE, and RQS_Setup.BAT. After confirming the files exist, do the following:

1. | Launch Notepad on the system (Start, Run, Notepad, OK). Load the RQS_Setup.BAT into Notepad.
2. | Search for the string "Version1\0" in the file (Edit, Find, Version1\0, OK). The result should return the string "REG ADD %ServicePath% /v AllowedSet /t REG_MULTI_SZ /d QScript1.0a".
3. | Delete the REM at the start of the line to make the line an active command line.
4. | Save the file (File, Save) and exit (File, Exit).
5. | Type RQS_Setup/install to configure the registry settings needed for the Quarantine Policy Check software to work properly.

RQS_Setup /install installs all of the necessary files in the c:\system32\RAS folder on the server system.

Note

RQS_Setup/install does not start the Remote Access Quarantine Agent service, nor is the Remote Access Quarantine Agent service configured to start automatically. The agent requires the RRAS service to start before it starts.

After the RQS Registry settings have been set up and configured, a script file should be created and a CM Profile created and installed on remote client systems.

Note

To remove RQS.EXE, type RQS_Setup /remove and the setup file will remove the Registry settings added during the installation process.

Creating a Script File for Post-Connection Execution

During the Quarantine Policy check process, a script is run to check the status of system parameters on the remote client system. Dependent on the results of the script, the remote system either is logged on to the network or is quarantined for further system updates.

The script file can be set to look for specific system variables or parameters that indicate the status of patch installations, antivirus software checks and updates, and so on. A sample script file is shown here. The %1, %2, %3, and %4 variables will be passed to the batch file when the batch file is executed. The variables will be highlighted in the next section of this chapter, "Creating a Quarantine Connection Manager Profile."

@echo off
REM This file should be saved as script.bat

echo RAS Connection = %1
echo Tunnel Connection = %2
echo Domain = %3
echo User Name = %4

set MYSTATUS=

REM
REM Check if Internet Connection Firewall is enabled.
REM Set ICFCHECK to 1 if it is (pass).
REM Set ICFCHECK to 2 if it is not (fail).
REM
REM Check if Virus checker is running and has correct signature file installed.
REM Set VIRCHECK to 1 if it is (pass).
REM Set VIRCHECK to 2 if it is not (fail).
REM
REM Based on the test results, run Rqc.exe.
REM

if "%ICFCHECK%" == "2" goto :TESTFAIL
if "%VIRCHECK%" == "2" goto :TESTFAIL

rqc.exe %1 %2 7250 %3 %4 Version1

REM %1 = %DialRasEntry%
REM %2 = %TunnelRasEntry%
REM 7250 is the TCP port on which Rqs.exe is listening
REM %3 = %Domain%
REM %4 = %UserName%
REM Version1 is the script version string

if "%ERRORLEVEL%" == "0" (
 set MYERRMSG=Success!
) else if "%ERRORLEVEL%" == "1" (
 set MYERRMSG=Unable to contact remote access gateway.
 Quarantine support may be disabled.
) else if "%ERRORLEVEL%" == "2" (
 set MYERRMSG=Access denied. Please install the Connection Manager profile from
http://www.companyabc.com/VPNDenied.htm and reconnect.
) else (
 set MYERRMSG=Unknown failure. The client will remain in quarantine mode.
)
echo %MYERRMSG%
goto :EOF

:TESTFAIL
echo
echo Your computer has failed network compliance tests. Either
echo Internet Connection Firewall is not enabled or you do not
echo have the correct virus-checking program with the current
echo signature file loaded. For information about how to configure
echo or install these components, see
echo http://www.companyabc.com/remote_access_tshoot.htm.
echo

:EOF

This is just a sample of what the script.bat file can screen for during the connect process. The batch file can be customized for the specific needs of the organization.

Creating a Quarantine Connection Manager Profile

After a script batch file has been created, a new quarantine Connection Manager (CM) profile needs to be created with the Windows 2003 Connection Manager Administration Kit (CMAK). The CM Profile will be part of the remote client access connection manager configuration that instructs the remote client system to launch the script.bat file and prepare information that the Quarantine Policy Check Server will be able to validate that the remote system can connect to the network.

The CMAK is a Windows component of Windows Server 2003. To install the CMAK, do the following:

1. | Click on Start, Settings, Control Panel, Add/Remove Programs.
2. | Click on the Add/Remove Windows Components icon in the left frame.
3. | Scroll down and highlight Management and Monitoring Tools and click on Details.
4. | Click to select the Connection Manager Administration Kit, then OK, and then Next to install the component.
5. | Click Finished when prompted.

After CMAK has been installed, a custom action needs to be configured in a profile that will be distributed to remote client systems. To configure the custom action, do the following:

1.
Launch the CMAK (Start, Programs, Administrative Tools, Connection Manager Administration Kit).

2.
At the Welcome screen, click Next.

3.
For Service Profile Selection, choose to create a New Profile, and click Next.

4.
For Service and File name, enter a description name for the server (such as CompanyABC Connection) and for the filename, name of a file (like cmprof), and then click on Next.

5.
If you have a realm name, enter it; otherwise just choose Do Not Add A Realm Name To The User Name and click Next.

6.
If you have an existing profile, choose to merge the profiles; otherwise just click Next.

7.
For VPN support, typically because the connection manager profiles are to secure VPN connections, choose the check box Phone Book From This Profile, and under VPN Server Name Or IP Address, enter the VPN name that the remote client will be accessing and click Next.

8.
Your newly created profile will appear at the VPN Entries screen. Choose to edit any settings at this point, or click Next to continue.

9.
If a static phone book will be used, enter it in the Phone Book File location; otherwise keep Automatically Download Phone Book Updates and click Next.

10.
If you did not enter a phone book filename in the previous screen, enter a phone book name such as pbook, and for the Connection Point server name, enter the URL for the server. Click Next to continue.

11.
At the Dial-up Networking entries screen, your newly created profile will appear. Choose to edit any settings at this point, or click Next to continue.

12.
If you plan to change routing tables, enter the routing file; otherwise click Next.

13.
If your remote connection requires a proxy setting, enter it in the Automatic Proxy Confirmation page; otherwise, click Next.

14.
Finally, to configure the Custom Actions for the Quarantine Policy Check, click the New button to bring up the New Custom Action page.

15.
Enter a description (such as Quarantine Policy Check), program to run (such as script.bat), parameters (%DialRasEntry% %TunnelRasEntry% %Domain% %UserName%). Choose Post-connect for the Action type, choose All Connections for the type of connection that the action will run, and make sure the two check boxes at the bottom of the page are selected. The configuration will look something similar to Figure 26.12. Click OK when this is completed.

Figure 26.12. New custom action configuration for Quarantine Check.

16.
Click Next to get to the Logon Bitmap screen, and either enter a new graphic or leave it on the default and click Next to continue.

17.
For Phone Book Bitmap, either enter a new graphic or leave it on the default and click on Next.

18.
On the Icons page, choose new icons, or leave with the default icons and click on Next.

19.
Choose a new shortcut menu command, or leave the default and click Next.

20.
Select a new Help file or leave the default and click Next.

21.
Enter in a Support Information contact line, such as Call Corporate Helpdesk for Support (510) 555-1234 so that users with problems have a contact number for assistance. Click Next.

22.
If your users do not have the Connection Manager v1.3 installed on their system, by selecting the Installation option, Connection Manager 1.3 will be installed with the profile. Click Next.

23.
For any organization disclaimers, such as notices of privacy, security, appropriate use, or the like, a text file can be displayed at the time of logon. Enter the filename (or leave blank) and click Next.

24.
If you have additional files that need to be launched, click Add and specify rqc.exe in the \Program Files\Windows Resource Kits\Tools\ directory. Click Next.

25.
Choose Advanced customization and then Next to give the customization file a unique value. In the example used to create the RQS_Setup.bat, the authorized versions were Version 0, Version 1, and Test. If you plan to allow this connection manager to work, choose an option like Test for the "value" as shown in Figure 26.13. Click Apply and then click Next. You will notice a DOS session open that will configure the Connection Manager settings.

Figure 26.13. Advanced Customization screen.

[View full size image]

26.
Click Finished when done.

After creating the CM Profile, the files stored on the RRAS server in the \Program Files\Cmak\Profiles\cmprof directory need to be distributed to remote users accessing the network. Use any number of software distribution tools to deploy the CM Profile files, such as using a Group Policy, Logon Script installation, or Microsoft Systems Management Server (SMS).

Launching the CM Profile on Remote Access Client Systems

After the CM Profile has been created with the CMAK and distributed to remote access client systems, the executable file created (cmprof.exe in the case of the file created from the "Creating a Quarantine Connection Manager Profile" section) needs to be run. When executed, the file installs the connection manager system profile that creates a network connection icon on the remote system.

When remote users launch the network connection icon, they are prompted with the information entered into the CMAK configuration wizard. In the example in the "Creating a Quarantine Connection Manager Profile" section, the user will see a screen similar to the one in Figure 26.14.

Figure 26.14. Network connection by remote access user.

If the remote access user settings do not comply with the settings defined in the script.bat file, the user logon will be halted, effectively quarantining the user session until action is taken. The action, dependent on what was noted in the CMAK, may be to send users to a Web site where they are prompted to call for help desk support or to install certain patches and updates, or the remote system may be scanned, cleaned, and updated automatically.


Remote Access Scenarios

To help you better understand how Routing and Remote Access can be leveraged in an enterprise environment, we've created a couple of scenarios. The following two scenarios include mobile and home user access of RRAS and a site-to-site connected RRAS environment.

Remote Mobile and Home Users

Remote access users connecting from home or a hotel have several options. The connection options depend on the available hardware connection and the version of the Windows desktop operating system. The following list discusses some options available to remote mobile and home users:

  • Dial-up remote access Remote and mobile users can access corporate network resources by dialing up to an RRAS server. The dial-up client, shown in Figure 26.15, initiates a connection to an RRAS server to authenticate the user and then provides access to the corporate intranet.

  • Windows Terminal Services (WTS) Windows Terminal Services provides remote and mobile users access to Windows-based programs running on a Windows Server 2003. With WTS, users can run programs, open and save files, and use corporate network resources as if they were installed on their local computers. Using Windows Server 2003 WTS also allows users to access their local drives for file transfers, access serial devices, and print to their local printers. Remote home users can access the WTS server through direct dial-up, Internet Explorer (requires an ActiveX plug-in), and Windows Terminal Server Client. Terminal Services is covered in detail in Chapter 27, "Windows Server 2005 Terminal Services."

  • VPN connection Remote and mobile users who have access to the Internet can create VPN connections to establish remote access connections to a corporate intranet. VPN remote access eliminates the need for long-distance calls to corporate RAS servers. Remote clients can use their connections to local ISPs to create VPN connections to their corporate office. The VPN software creates a virtual private network between the dial-up user and the corporate VPN server across the Internet. VPN clients have a choice of connecting using PPTP or L2TP or having the connection automatically selected, as shown in Figure 26.16. As stated earlier in this chapter, PPTP is supported by a variety of Windows desktop platforms but does not have the level of security provided by L2TP/IPSec. L2TP/IPSec provides a higher level of data integrity and security but requires a certificate infrastructure.

Figure 26.15. Dial-up window to connect to an RRAS server.

Figure 26.16. Choosing between PPTP, L2TP, or automatic connection type.

Site-to-Site Connections

Organizations can also use VPN connections to establish routed and secure connections between geographically separate offices or other organizations over the Internet. A routed VPN connection across the Internet logically operates as a dedicated WAN link. The two methods for using VPNs to connect local area networks at remote sites are as follows:

  • Using dedicated lines to connect branch offices Rather than using an expensive dedicated circuit between the branch offices, both the branch office RRAS servers can use a local dedicated circuit and local ISP to connect to the Internet. The VPN software uses the local ISP connections and the Internet to create a virtual private network between the branch office servers.

  • Using a dial-up line to connect branch offices Instead of having an RRAS server initiate a long-distance call to another RRAS server, the server at each branch office can call a local ISP to establish a connection to the Internet. The VPN software uses the Internet connection to create a VPN between the branch office servers across the Internet, as illustrated in Figure 26.17.

Figure 26.17. Using the Internet to create a branch officetobranch office connection.

In both cases, the services that connect the branch offices to the Internet are local. The office routers that act as VPN servers must be connected to a local ISP with a dedicated line. This VPN server must be listening 24 hours a day for incoming VPN traffic.


Summary

Remote and mobile connectivity has increased over the years because the extended office now includes hotels, airports, client sites, other campus buildings, and wireless users. With the expansion of the network from which users need to connect to a Windows Server 2003 environment, the improvement of security, reliability, compatibility, and performance becomes extremely important for an organization. Windows Server 2003 Routing and Remote Access Services (RRAS) includes all the enhancements added to the technology over the past several Windows Server product revisions, and includes several new technologies that further expand the capability of the technology. Although it may not have met all the needs of organizations in the past, RRAS now provides an extremely robust set of tools, technologies, and utilities to implement, support, monitor, and manage a truly enterprise-mobile communication environment.


Best Practices

  • Use the EAP-TLS authentication protocol for both PPTP and L2TP connections.

  • Use EAP-TLS if a smartcard will be used or if a certificate infrastructure that issues user certificates exists.

  • Use MS-CHAP v2 and enforce strong passwords using Group Policy if you must use a password-based authentication protocol.

  • Use IPSec to provide per-packet data authentication (proof that the data was sent by the authorized user), data integrity (proof that the data was not modified in transit), replay protection (prevention from resending a stream of captured packets), and data confidentiality (prevention from interpreting captured packets without the encryption key).

  • L2TP/IPSec connections provide stronger authentication by requiring both computer-level authentication through certificates and user-level authentication through a PPP authentication protocol.

  • PPTP does not require a certificate infrastructure. L2TP/IPSec requires a certificate infrastructure for issuing computer certificates to the VPN server computer (or other authenticating server) and all VPN client computers.

  • Use PPTP for versions of Windows prior to Windows 2000 and Windows XP.

  • Configure a remote access solution automatically using the Connection Manager Administration Kit for an environment with a hundred or more remote access VPN clients.

  • Use logging sparingly to help identify network problems because logging remote access activity uses system resources.

  • To minimize the risk of remote-access users bringing viruses and worms into the network, use the Quarantine Client Check utility in the Windows Resource Kit to make sure remote systems meet minimum organizational update policies.

  • Do not leave tracing enabled on multiprocessor computers.


Chapter 27. Windows Server 2003 Terminal Services

In This Chapter

  • Why Implement Terminal Services?

  • How Terminal Services Works

  • Leveraging Terminal Services Features

  • Planning for Terminal Services

  • Deploying Terminal Services

  • Configuring Terminal Services

  • Installing a Terminal Services License Server

  • Installing and Configuring Fault-Tolerant Terminal Services

  • Securing Terminal Services

  • Sizing and Optimizing Terminal Services Environments

  • Supporting Terminal Services

  • Accessing a Terminal Server

Windows Server 2003 Terminal Services is a client/server system that enables clients to remotely run applications or manage a server from any node with a Terminal Server client and network access. In a Terminal Server session, whether a client requires a complete remote desktop environment or just needs to run a single application, the Terminal Server performs all the processing and uses its hardware resources. In a basic Terminal Server session, the client sends out only keyboard and mouse signals and receives video images, which requires only a small amount of bandwidth on the network. For a more robust multimedia-intensive session, Terminal Services provides true-color video support along with audio, local printer, COM port, and local disk redirection to provide ease of data transfer between the client and server through a single network port. Terminal Services also provides local time zone redirection, which allows users to view time stamps of email and files relative to their location.

A Terminal Services implementation can provide remote administration services, but also can be used as a centralized application server, thus reducing the need to deploy high-end workstations to end users who rarely need high performance on their local workstations. A Terminal Services implementation can also improve network performance for enterprise messaging, database applications, and other multitiered applications by reducing the amount of network traffic each backend server and network device needs to process. Costs in desktop application support can also be reduced as a result of a Terminal Services implementation by limiting application upgrades and security patch installations to the Terminal Server instead of the administrator having to visit every workstation.

In this chapter, planning, implementation, management, and support of Windows Server 2003 Terminal Services systems are covered. This chapter addresses not only the new features added in Windows Server 2003, but also how these new technologies can be leveraged to improve remote access services by users, as well as administration and management by network administrators.


Why Implement Terminal Services?

Terminal Services is a versatile product that can be implemented to meet several different business needs. Administrators can use it to remotely administer a server, or users can run applications and utilize network resources remotely. Terminal Services can be accessed and used by local area network (LAN) users and remote Internet-based users, to provide access to a single application or a full desktop environment within a terminal session. User desktop support can also be provided to users while running in Terminal Server sessions or if the users are working on desktops running Windows XP Professional with Remote Desktop enabled.

Note

Windows XP Professional includes a scaled-down version of Windows Server 2003 Terminal Services that can be enabled and used for remote administration or remote workstation console access.

Lastly, Terminal Services can be implemented by application service providers (ASPs) to create managed application services to which clients can subscribe. This eliminates the need for each business to buy server hardware, software, and support.

Remote Desktop for Administration

As a remote administration tool, Terminal Services technology gives an administrator the option of performing server administration from the server console or from any other server or workstation with a Terminal Services client. This option is installed by default, but is not automatically enabled. This capability simplifies administration for the IT department by allowing the personnel to do their job from almost any console on the network. This can improve IT response times to complete trouble tickets concerning access to network resources or user account management. Server maintenance tasks such as reviewing logs or gathering server performance data can be accomplished through the client.

Applications and updates can be installed through a Terminal Server session, but should be done only when the installation does not involve a Windows Component installation or when users are running Terminal Services server sessions. Installing applications from the local server console is recommended, but if an application must be installed remotely, you should connect to the server console to run the session.

Caution

Avoid installing applications, especially Windows Server 2003 services and Windows components, from within a Terminal Services server session. This way, you avoid getting locked out of your Terminal Services server sessions and not being able to recover.

Terminal Services for LAN Users

There are many benefits of making Terminal Services available to LAN users. Company hardware costs can be reduced, application availability and licensing management can be simplified, and network performance may increase.

Because a terminal session is really a virtual desktop session running on the Terminal Server, all Terminal Server users run applications on the Terminal Server, utilizing the processing power of the server while reducing the load on the local workstation. This can extend the life of an underpowered machine whose deficient resources may impede workflow through high processor, memory, or disk utilization.

From a desktop support perspective, a Terminal Server can be put in place and used as a secondary means of providing users access to their applications if problems are encountered with the applications on their local workstations. Although this approach may seem to be overkill, providing a secondary means of application access can be vital to user productivity and company revenue when support personnel may not be readily available to fix end user application issues.

Providing centralized applications for LAN users though Terminal Services can simplify application management by reducing the number of machines on which application upgrades, security updates, and fixes need to be installed. Because all the applications run on the Terminal Services server, only the Terminal Services server itself needs to be updated, and the entire user base benefits from the change immediately. This way, the updates can be performed for all Terminal Services server users at one time.

Terminal Services for Remote User Support

Terminal Services can be used to provide application support for end users within a Terminal Server session. When users are running in a Terminal Server session, an administrator can configure remote control or shadowing functionality to view or completely interact with a user's session. This feature can be used to train users, provide application support, or create configuration changes such as installing a printer or connecting to a network file share. This capability can greatly reduce the number of administrators needed during the regular work day because multiple users can be assisted from one location.

Note

To comply with many organizations' security and privacy polices, Windows Server 2003 Terminal Services provides an option for the remote control function to be completely disabled. Alternatively, rather than completely disabling the function for all users, Terminal Services can be configured to give users the ability to choose whether or not to allow an administrator to interact with her terminal server session.

Terminal Services for Application Service Providers

Terminal Services running in Terminal Server mode allows applications and services to be made available to users in any location. Companies that provide services to businesses through proprietary applications can standardize and provide their applications exclusively through Windows Server 2003 Terminal Services and gain all the benefits outlined in the preceding LAN and remote user sections. An added bonus for these companies is that Terminal Services reduces the need to send application media out to each client, and end user support can be provided in a way never before possible.

Application service providers who make several applications available to clients can use Terminal Services to service hundreds or thousands of users from different organizations while charging a fee for application usage or terminal session time usage.

Note

Windows Server 2003 does not provide a standard reporting mechanism to present Terminal Services session data. However, some valuable information can be gathered by filtering the security event log for user logon and logoff events, using the Terminal Services Licensing Reporter (lsreport.exe) from the Windows Server 2003 Resource Kit, as well as teaming this information with data gathered by creating performance logs configured to monitor Terminal Server Services session counters using the Performance Microsoft Management Console (MMC) snap-in, included with Windows Server 2003. It is also important to note that Microsoft Operations Manager (MOM) and some third-party solutions for Terminal Services provide exceptional reporting functionality.


How Terminal Services Works

Terminal Services provides a client/server session that creates a virtual desktop within a single client window that emulates a true local desktop environment. Using primarily keyboard and mouse redirects, Terminal Services clients run applications on the Terminal Server, so almost no processing power is needed on the client system.

The Terminal Services client software communicates with the Terminal Services server by redirecting the local workstation's keyboard and mouse signals to the Terminal Server. These commands are sent to the Terminal Server via a single TCP port (3389), and only minimal network bandwidth per user is needed. In fact, so little network bandwidth is needed that Terminal Server clients can connect to Terminal Servers using 28.8Kbps modem connections. For richer terminal sessions utilizing advanced features such as port redirection, color settings higher than 256 colors, file transfer, and 128-bit encryption, increased line speed is recommended.

Modes of Operation

Windows Server 2003 Terminal Services can be run in two different modes of operation. One is called the Remote Desktop for Administration mode and the other is called Terminal Server mode.

Remote Desktop for Administration Mode

Terminal Services Remote Desktop for Administration mode is included and installed with the Windows Server 2003 operating system and only needs to be enabled. This eases automated and unattended server deployment by allowing an administrator to deploy servers that can be managed remotely after the operating systems have completed installation. This mode can also be used to manage a headless server, which reduces the amount of space needed in any server rack. More space can be dedicated to servers instead of switch boxes, monitors, keyboards, and mouse devices.

The Remote Desktop for Administration mode limits the number of terminal sessions to two, and only local administrators can connect to these sessions by default. No additional licenses are needed to run a server in this Terminal Services mode, which allows an administrator to perform almost all the server management duties remotely.

Even though Remote Desktop for Administration is installed by default, this mode does not have to be enabled. Some organizations may see this as an unneeded security risk and choose to keep it disabled. This function can easily be disabled throughout the entire Active Directory forest by using a Group Policy setting to disable users and groups from connecting to Terminal Servers located in the containers that the policy applies to. This mode of Terminal Services is available in every Windows Server 2003 version as well as in Windows XP Professional.

Terminal Server Mode

Terminal Server mode allows any authorized user to connect to the server and run a single application or a complete desktop session from the client workstation.

Running Terminal Services in this mode requires the purchase of a Terminal Server client access license (CAL) for each simultaneous connection. To manage these CALs, a Terminal Services License server is needed to allocate and track the licenses for the Terminal Server. The Terminal Services License server service can be installed on any Windows Server 2003 Enterprise or DataCenter server. The License server does not need to have Terminal Services enabled in any mode to run this service.

Note

To quickly obtain client license information on a client computer, use the Windows Server 2003 Resource Kit tool called Terminal Server Client License Dump (TscTst.exe).

Installing applications for Terminal Server mode requires that a strict process be followed to ensure that each application runs as it should in multiple user sessions. Some applications may not be properly suited to run on a Terminal Server; in such cases, special Terminal Server application compatibility scripts need to be run against the programs for these applications to run correctly. Thorough testing of each Terminal Server application is highly recommended before it is released into the production Terminal Server environment.

Note

Terminal Server mode is not available in Windows Server 2003 Web edition.

Client-Side Terminal Services

Windows XP Professional includes a scaled-down version of Terminal Services called Remote Desktop. Remote Desktop allows a user to connect to the XP workstation and remotely take over the workstation to run applications that he would normally run from his desk locally. This feature allows a user who works from home part time to connect to the company workstation to complete work or check email from a workstation that is already configured for him.

As an administration tool, this client-side Terminal Services can be used to install software on an end user's workstation from a remote machine. Also, it can be used to log in to a user's desktop environment to remotely configure a user's profile settings.

Remote Assistance

Remote Assistance is a feature new to Windows Server 2003 and Windows XP Professional. This feature allows a user to request assistance from a trusted friend or administrator to help deal with desktop issues and configurations. This feature gives the end user the power to control what level of participation the remote assistant can have. The remote assistant can be granted the ability to chat with the end user, view the desktop, or remotely control the desktop. During remote assistance sessions, both the end user and remote assistant can hand off control of the keyboard and mouse. Remote assistance uses the underlying Remote Desktop Protocol (RDP) used by Terminal Services.

Remote Desktop Connection

Remote Desktop Connection is the newly improved and renamed Terminal Server client. This full-featured client now enables the end user to control Terminal Server session settings such as local disk, audio, and port redirection, plus additional settings such as running only a single program or logging on automatically. Remote Desktop Connection information can be saved and reused to connect to Terminal Servers with previously defined session specifications.


Leveraging Terminal Services Features

Although some of the uses of Terminal Services have already been touched on, this section covers the features that enhance the basic Terminal Server sessions.

Using Local Resource Redirection Functionality

Terminal Services enables a Terminal Server client to redirect many of the local resources so they can be easily used within the Terminal Server session. Serial and printer ports can be made available in Terminal Server sessions to allow a user to send Terminal Server print jobs to locally configured printers, as well as access serial devices such as modems from within the Terminal Server session. Audio can also be redirected from a session to local sound cards to enable sound from the terminal session to be heard from local speakers. Also, the Windows Clipboard can be redirected to allow cutting and pasting between the Terminal Server session and the local workstation console.

Each of these resource redirections works only if the operating system and the Terminal Services client on the end user's workstation support these configurations. Some of these local resource redirections require user modification or reconfiguration for proper use. Some of the common changes are described next.

Disk Drive Redirection

Local disk drives can be redirected to Terminal Services sessions and appear in the Windows Explorer as networked drives using the naming convention local drive letter on computer namefor example, C on workstation5. There is no level of granularity here; all local drives are redirected, including floppy and CD-ROM drives. To access from a graphical window, simply browse the drive as you would a local or networked drive. Accessing this drive from the command prompt requires a little bit of education. Within a command prompt, the redirected local drives are referenced as \\tsclient\Drive letter. Directory listings can be created using this UNC, but for file transfer or quick browsing, a client should map a network drive letter to this local drive resource. To do so, follow these steps:

1. | Open a command prompt.
2. | Type net use * \\tsclient\c, where the local C: drive is the disk you want to access within the command-prompt window. The local drive is automatically mapped to the next available drive letter, starting from drive letter Z: and working backward through the alphabet.
3. | At the command prompt, type Z: and press Enter to connect directly to the mapped local drive and begin using this drive.
4. | After you finish working with this resource, disconnect the drive by typing net use Z: /delete, where the Z: drive is the local mapped drive.
5. | Close the command-prompt window. Caution The preceding steps refer to a machine called tsclient. You should not replace this name with the actual machine account name. The Terminal Server session recognizes the machine's local disk resources only from within a terminal session command window by tsclient, so do not consider this a substitute for the actual machine name.
Printer Redirection

With the Windows Server 2003 version of Terminal Services, locally defined print devices can also be redirected. This includes printers directly attached to the client workstation as well as network printers. When a client opens a Terminal Services session that is configured to redirect window printers as well as LPT ports, the Terminal Server attempts to install each printer for use in the Terminal Services session. If the local print device is using a print driver native to Windows Server 2003, the printer will be automatically installed and configured to the specifications configured on the end user's desktop. If the local print device is using a foreign driver, the printer must be installed and configured manually in the Terminal Services session. To install these types of printers, it is best to have an administrator install them; however, the end user can do so with the appropriate permissions. When the port is requested, the correct client workstation port must be specified. This port is named computername:PortX, where PortX is used to describe the type of portfor example, workstation1:lpt1.

Local Time Zone Redirection

Windows Server 2003 Terminal Server supports local time zone redirection. This allows a Terminal Server client connecting from a separate time zone to have the session time reflect the user's local time, enabling users to more easily comprehend the times, especially when reviewing emails.

Using Session Directory Server

Session Directory server introduces a new level of resilience and fault tolerance for Terminal Server session management. The Terminal Server allows a session to remain active even when the client becomes disconnected. This enables users who encounter network connectivity issues between the client and server to reconnect and resume the disconnected session where they left off. Users who need to take a break or attend a meeting can manually disconnect from a session. When a user returns, all the user needs to do is start a connection to the Terminal Server and the session will be resumed.

Many environments with large numbers of users to support sometimes use network load-balanced Terminal Server cluster farms to evenly distribute the session load across multiple servers. If a user forcibly or unexpectedly disconnects from a Terminal Server session on a clustered Terminal Server, chances are that upon reconnection the user will be connected to a different cluster node and start a new session. This occurs because session information is not shared between cluster nodes.

With the introduction of the Session Directory server, participating Terminal Server cluster nodes send session information to the Session Directory server, where it is maintained. When a Terminal Server is part of a cluster that uses a Session Directory server, it sends a list of active sessions to the server periodically. When a user connects to a Terminal Server cluster to start a session, the particular Terminal Server node checks with the Session Directory server to make sure the user does not already have an active session on another Terminal Server cluster node. If a session is active, the user is redirected to the correct server to resume the disconnected session; otherwise, the session is started on the node that first answered the request.

The Session Directory server service is installed on all Windows Server 2003 Enterprise and Datacenter servers. The service need only be configured to run automatically to start using it. The Terminal Server cluster nodes must be configured to participate in a Terminal Services cluster and to send session information to the Session Directory server. This can be configured throughout the enterprise using Terminal Server Manager or Group Policies that apply to the Terminal Server computer objects. Also, for security purposes, each Terminal Server using the Session Directory server must be made a member of a local group on the Session Directory server called Session Directory Computers.

Tip

For best performance and to eliminate the risk of overlapping Terminal Services sessions, configure each Terminal Server node in a cluster to restrict each user to one Terminal Services session through Group Policy or in the Terminal Services Configuration (TSCC) snap-in.

Granular Session Control

With the addition of many great features in Terminal Services also comes the ability for a Terminal Server administrator to granularly control the configuration of Terminal Services sessions. All the features available to the end user's Terminal Services session can be managed, limited, and overridden by the Terminal Services administrator. Configuring administrative settings through Group Policy or Terminal Services Configuration can override most user-configurable settings. This can greatly benefit the Terminal Server by freeing the server from spending valuable server resources for features that may not be required in an enterprise deployment, such as audio redirection or high-color resolution.

With this granular administrative capability, the Terminal Services administrator can also improve Terminal Services server security by requiring high encryption for sessions or setting the Terminal Server to run in Full Security mode.

Terminal Server Console Access

Terminal Services clients can be configured to access a Terminal Server's console remotely. This improves the functionality of remote administration by allowing the administrator to perform tasks that could previously be accomplished only at the local server console. For instance, the administrator can view pop-up messages on the console or install software for the Terminal Server. Even though console access is available for pop-up messages, the Terminal Services administrator should use the event log to review all errors or alerts that may have been logged on the Terminal Server.

Terminal Server Fault Tolerance

In Windows 2000 Terminal Services, Terminal Services nodes could be clustered using network load balancing (NLB) to split the client load across several servers. This feature has been greatly improved in Windows Server 2003 with Session Directory server when using multiple Terminal Servers in an NLB configuration.

Note

Windows Server 2003 Terminal Services can be used with Microsoft Cluster Service (MSCS), but it is generally not recommended because of scalability constraints and increased manageability. Microsoft doesn't support using both MSCS and NLB on the same servers, and Terminal Services using MSCS doesn't provide session failover.


Planning for Terminal Services

To achieve the most successful Terminal Services project deployment, careful and thorough planning and testing must be performed prior to production rollout. Criteria such as application resource usage, security requirements, physical location, network access, licensing, fault tolerance, and information indicating how users will be utilizing the Terminal Server all contribute to the way the Terminal Services implementation should be designed.

Planning for Remote Desktop for Administration Mode

Unless Terminal Services is viewed as a security risk, it is recommended to enable Remote Desktop for Administration mode on all internal servers to allow for remote administration. For servers that are on the Internet and for DMZ networks, Terminal Services may be used, but access should be limited to predefined separate IP addresses using firewall access lists to eliminate unauthorized attempts to log on to the Terminal Server. In addition, those servers should be closely monitored for unauthorized attempts to access the system.

Planning for Terminal Server Mode

Terminal Server mode can require a lot of planning. Because this mode is used to make applications available to end users, server hardware specification and application compatibility are key components to test before a production rollout.

User Requirements

It is important to determine user requirements based on typical usage patterns, the number of users accessing the system, and the number of applications that are required to run. For instance, the more applications that a user will run in a session, the more processing power and memory will be required in order to optimize session performance. On average, a Terminal Server user who runs one application may take 10MB of RAM and use little more than 3% of a server's total processing time per session. A power user who runs three or more applications simultaneously may require 40MB of RAM or much more, depending on the applications and features being used. Use the Terminal Services Manager tool and the Performance System Monitor console to test and validate usage statistics. The key is to not overload the server to the point where performance is too slow to be cost effective. Bandwidth to the Terminal Server required by each user will also affect how well the system performs under various workloads.

Antivirus on Terminal Services

Just as standard servers require operating system (OS)level antivirus software, so do Terminal Servers. When choosing an antivirus product, be sure to choose one that is certified to run on Windows Server 2003 Terminal Servers. For Terminal Server mode deployments, install the antivirus software after installing the Terminal Server so that scanning will work for all Terminal Server sessions. Follow installation guidelines for installing applications as outlined in the "Installing Applications for Terminal Server" section later in this chapter.

Terminal Server Upgrades

Upgrading Terminal Servers can be tricky and should be handled with caution. Before any operating system or application updates or patches are applied on a production Terminal Server, they should be thoroughly tested in an isolated lab server. This process includes knowing how to properly test the application before and after the update to be sure the update does not cause any problems and, in some cases, adds the functionality that you intended to add.

When a Terminal Server's operating system is to be upgraded to the next version, many issues can arise during the upgrade process. Applications may not run properly in the next version because key system files might be completely different. Even printer drivers can be changed drastically, causing severe performance loss or even loss of functionality. Lastly, you need to consider that the existing Terminal Server could have been modified or changed in ways that can cause the upgrade to fail, requiring a full restore from backup.

Note

Complete disaster recovery and rollback plans should be available during upgrades. This way, if problems arise, the administrator does not have to create the plan on the spot ensuring that no important steps are overlooked.

As a best practice and to ensure successful upgrades of Terminal Servers, replace existing servers with clean built Terminal Servers with the latest updates. This includes re-creating each of the file shares and print devices and using the latest compatible drivers to support each of your clients. Avoid upgrading a Terminal Server from Windows NT 4.0 to avoid driver and application conflicts. You can upgrade Windows 2000 Terminal Servers to Windows Server 2003 rather easily. However, to make your Terminal Server operating system upgrade as painless as possible, replace the existing server with a new one. If necessary, rebuild the old server from scratch and redeploy to the production environment if the hardware can still meet performance requirements.

Physical Placement of Terminal Servers

Place your Terminal Servers where they can be readily accessed by the clients that will primarily be using them. Also, to keep network performance optimized, try to place Terminal Servers on the same network segment as other servers that clients may use in their session, such as domain controllers, database servers, and mail servers, as shown in Figure 27.1. This way, you can reduce traffic on the network and improve Terminal Server performance. However, if security, as opposed to performance, is of concern, you should place the Terminal Server system between the client and the servers to create a barrier between external and internal resources.

Figure 27.1. Reducing network traffic using Terminal Services.

Planning for Hosted Applications

Whenever possible, choose applications that have been tested and certified by Microsoft to run on Windows Server 2003 Terminal Servers. If you must run third-party applications on Terminal Services, run the necessary compatibility scripts provided with Windows Server 2003, when applicable, and also review the software vendors' information on installing the applications on a Windows Server 2003 Terminal Server. Certified or compatible applications should be capable of running multiple instances simultaneously on the server as independent processes. Test applications completely to note the resource requirements and functionality.

Networking Requirements

To keep Terminal Server sessions running efficiently, adequate available network bandwidth is a must. A Terminal Server requires network access to each Terminal Server client, along with any other server the client accesses during that session. For optimum performance for multitiered applications, install two or more network cards on a Terminal Server and configure the server to use one exclusively for Terminal Server client connectivity and the others for back-end server communication.

Terminal Server Fault Tolerance

A fault-tolerant Terminal Server environment can be created using Windows Server 2003 NLB or other hardware vendor load-balancing technologies. If using a third-party load-balancing solution, also ensure that it supports Session Directory server for session failover capabilities, or provides a similar solution. This increases server availability and also gives administrators the flexibility to remove a specific Terminal Server from production without affecting the availability of the Terminal Server environment.

Keep in mind that if a Terminal Server session is disconnected from a failed network load-balanced Terminal Server, the disconnected session is lost and a completely new session must be started on a remaining Terminal Server node if Session Directory server is not used. Also, upgrades and patches need to be performed on each node in the cluster independently.

Note

Refer to Chapter 31, "System-Level Fault Tolerance (Clustering/Network Load Balancing)," for NLB configuration and installation assistance.

Working with Terminal Server Licensing

Terminal Services deployed in Terminal Server mode requires the purchase of client access licenses (CALs) for each client device or session. Also, a Terminal Services License server must be available on the network to allocate and manage these client access licenses. When a Terminal Server is establishing a session with a client, it checks with the Terminal Services License server to verify whether this client has a license. A license is allocated if the client does not already have one.

To install licenses on the Terminal Services License server, the Terminal Services License server must first be installed and then activated online. To activate the Terminal Services License server, the wizard can automate the process or the administrator can choose to activate the server using a Web page form or by calling the Microsoft Clearing House via an 800 number to get an activate key.

When a Terminal Server cannot locate a Terminal Services License server on the network, it still allows unlicensed clients to connect. This can go on for 120 days without contacting a License server, and then the server stops serving Terminal Server sessions. This is why it is imperative to get a Terminal Services License server installed on the network as soon as possible or before Terminal Servers are deployed to production.

When servers are running in Terminal Services Remote Desktop for Administration mode, no CALs are required, so no Terminal Services License server is required either.


Deploying Terminal Services

After you take the time to carefully plan Terminal Services deployment in the enterprise, the installation can begin. After the planning phase of a Terminal Services deployment, the service and applications can be installed and configured and later tested by the IT personnel or a designated pilot group. After all functionality and applications are tested and verified, the Terminal Server can be released to the production end users or clients.

For the step-by-step instructions in the following sections, the desktop environment uses the Windows Server 2003 standard Start menu. To verify the Start menu is in this mode, perform the following steps:

1.
Right-click the Start button and click Properties.

2.
On the Start Menu tab, be sure that Start Menu is selected as shown in Figure 27.2 and click OK.

Figure 27.2. Setting the system's Start menu.

Enabling Remote Desktop for Administration

Terminal Services Remote Desktop for Administration mode is installed on all Windows Server 2003 servers by default and only needs to be enabled. To enable this feature, follow these steps:

1.
Log on to the desired server with Local Administrator privileges.

2.
Click Start, right-click the My Computer shortcut, and then click Properties.

3.
Select the Remote tab, and under the Remote Desktop section, check the Allow Users to Connect Remotely to This Computer check box, as shown in Figure 27.3.

Figure 27.3. Allowing users to connect to the system remotely.

4.
A Remote Sessions dialog box will open stating that accounts must not have blank passwords to use Remote Desktop; click OK to continue.

5.
Click OK in the Systems Properties page to complete this process.

Enabling Remote Assistance

To configure remote assistance, follow these steps:

1.
Log on to the desired server with Local Administrator privileges.

2.
Click Start, right-click the My Computer shortcut, and then click Properties.

3.
Select the Remote tab, and under the Remote Assistance settings, check the Turn On Remote Assistance and Allow Invitations to Be Sent from this Computer check box.

4.
Click the Advanced button to configure whether remote control will be allowed and also to set an expiration policy for remote assistance invitations as shown in Figure 27.4.

Figure 27.4. Enabling a computer for remote control.

5.
Click OK in the Advanced window and click OK in the System Properties page to complete this process.

Remote assistance for domain computer accounts can be configured using Group Policy. The following two settings are located in Computer Configuration\Administrative Templates\System\Remote Assistance, as shown in Figure 27.5:

Figure 27.5. Group Policy administrative templates for remote assistance.

[View full size image]

  • Solicited Remote Assistance This particular setting contains the same options available in the Remote System property page, previously described in this chapter. Use this setting to configure remote assistance standards across multiple workstations and servers.

  • Offer Remote Assistance This setting can be configured only using Group Policy. Offer Remote Assistance allows a predefined "helper" to request a remote assistance session from another workstation on the network. Enabling this setting still leaves the end user with the control to allow or decline a session and also to set the level of remote assistance allowed.

Installing Terminal Server Mode

To install Terminal Services in Terminal Server mode, a Terminal Server administrator can use the Configure Your Server Wizard as follows:

1.
Log on to the desired server with Local Administrator privileges.

2.
Insert the Windows Server 2003 CD in the CD-ROM drive and close any autorun pop-up windows that open.

3.
Click Start, All Programs, Administrative Tools, Configure Your Server Wizard, as shown in Figure 27.6.

Figure 27.6. Selecting the Configure Your Server Wizard option.

4.
Click Next on the Welcome screen to continue.

5.
Verify that you have completed the steps as outlined on the Preliminary Steps page and click Next to continue.

6.
From the Server Role page, shown in Figure 27.7, select Terminal Server from the list and click Next to continue.

Figure 27.7. Selecting to install Terminal Services on the Server Role page.

[View full size image]

7.
On the Summary of Selections page, Install Terminal Server should be listed in the summary. If this is correct, click Next to continue.

8.
When a pop-up warning message states that the server will be restarted as part of the installation process, click OK to continue.

9.
After the system restarts, log in with the same account used to install the Terminal Server.

10.
After the logon process completes, Terminal Server Help appears with direct links to Terminal Server checklists. Close this window or minimize it to review information later.

11.
When you see the Configure Your Server Wizard message stating This Server Is Now a Terminal Server, click Finish to complete the installation.

Installing Applications for Terminal Server

Applications should be installed on a Terminal Server after the Terminal Server is installed. Applications that are installed prior to installing the Terminal Server may not function properly for all users.

Applications must be installed on Terminal Servers only when the server is in Application Install mode. An administrator can put the server into Install mode by opening Add/Remove Programs from the Control Panel or at the command prompt. After the application is installed, the administrator can simply close the Add/Remove Programs window or change the server back to Execute mode at the command line. Execute mode allows users to access and use the applications from Terminal Server sessions.

To change modes at the command prompt, type

  • Change user /Install before installing an application

  • Change user /Execute after installing an application

  • Change user /Query to check which mode the server is currently running in

Several applications have special instructions for Terminal Server installations, whereas others require running application compatibility scripts. Microsoft has tested some third-party applications such as Eudora Version 4 to run on a Terminal Server, and it has provided the application compatibility script to run after installing that program on the Terminal Server. The provided compatibility scripts are located in %SystemRoot%\ Application Compatibility Scripts\install, where %SystemRoot% is the directory containing your operating system files. Consult your software manufacturer's documentation before deploying applications on a Terminal Server.


Configuring Terminal Services

Microsoft Windows Server 2003 Terminal Services can be managed and configured using several tools included with the operating system. This gives administrators flexibility and choice on how to manage Terminal Services in the enterprise. Because many of the tools described in the following sections overlap in function, their management and administrative functions will be described in the following sections. After you become familiar with each of these tools, you can decide which tool best fits your administrative needs.

Local Security Policy Settings

The Local Security Policy snap-in, as it applies to Terminal Services, is very limited but also very powerful. Only two settings can be configured for Terminal Services: Allow Logon Through Terminal Services and Deny Logon Through Terminal Services. These settings are located in Security Settings\Local Policies\User Rights Assignment.

By default, only the Local Administrators and Remote Desktop Users groups are allowed the right to log on through Terminal Services.

Using the Computer Management Tool

On a standalone or member server implementation of Terminal Services, user-specific Terminal Server settings can be configured using the Computer Management tool. Under the Local Users and Groups section, Terminal Server settings, including profile location, logon script, and remote control permissions, are configured by editing user property pages. Because these configurations are made on an individual user basis, they make administration tedious and inefficient.

Note

Terminal Server settings configured within the Computer Management tool override client-specified settings.

The User Properties pages for configuring Terminal Server settings are the Sessions, Environment, Remote Control, and Terminal Services Profile tabs, as shown in Figure 27.8. The terminal service profile settings for a user include profile path, home directory, and Terminal Server logon access.

Figure 27.8. The Terminal Services Profile tab in the Active Directory Users and Computers MMC snap-in.

The remaining tabs are covered in the "Terminal Services Configuration (Tscc.msc)" section. To use the Computer Management tool, choose Start, Administrative Tools, Computer Management.

Active Directory Users and Computers (Dsa.msc)

To manage domain user Terminal Server settings, use the Active Directory Users and Computers MMC snap-in available on all domain controllers and computers with the Windows Server 2003 Administration Tools installed. The user-specific settings here are similar to the settings configured using Computer Management, but they are for domain user accounts. See the next section to learn more about configuring user-specific Terminal Server settings.

Terminal Services Configuration (Tscc.msc)

The Terminal Services Configuration MMC snap-in is installed on all servers by default. It can be used only to change local Terminal Server configuration. This tool has two sections, Connections and Server Settings. These settings are set at the server level and override user settings.

Server Settings

This Terminal Services Configuration MMC snap-in section gives seven policies to configure:

  • Delete Temporary Folders on Exit This setting will delete user sessionspecific temporary folders when the user logs out of a terminal session. This setting only works if the setting to use temporary folders per-sessions is enabled or set to Yes.

  • Use Temporary Folders Per Session Terminal Server creates temporary folders on a per session basis. Disabling this setting makes all Terminal Server sessions use the same temporary folders.

  • Licensing Terminal Server supports per-device and per-session licensing mode. Choose the correct mode for your Terminal Servers.

  • Active Desktop This setting allows users to have active content in their Terminal Server sessions. Disabling this setting conserves server resources by reducing the amount of server processing and network power required to paint the session screens with active content on the desktop.

  • Permission Compatibility This setting offers two choices: Full Security and Relaxed Security. The choice here is made in regard to what resources users will need access to in order to properly run the applications installed on Terminal Server. Relaxed mode was created to support legacy applications.

  • Restrict Each User to One Session This setting was created to help support the Session Directory server for use with Terminal Server clusters. This setting allows users to reconnect to the correct node running the disconnected session by allowing only one session to run per cluster. You cannot reconnect to the wrong session if you have only one.

  • Session Directory This setting should be enabled if the Terminal Server is part of a cluster; it sends session data to a Session Directory server to manage disconnected terminal sessions.

Connections

In the Connections section of Terminal Services Configuration, the administrator can configure Terminal Server options such as session time limitations, number of maximum sessions, resource redirection policy, remote control permissions, logon settings, encryption settings, application permission levels, and whether the user can run just one application or have a full desktop session.

Within a defined Terminal Server connection object's property page, there are eight tabs to set configuration options:

  • General Within this tab, the Terminal Services administrator can configure the required client encryption level. Low encryption runs the Terminal Services sessions at 56-bit encryption; client-compatible encryption allows a client to connect at the highest negotiable encryption to the server; high encryption runs Terminal Services sessions at the highest encryption the Terminal Services server can handle; finally, FIPS Compliant encryption is the standard used by the U.S. government.

    Note

    If the client workstation does not support 128-bit encryption and the high encryption pack must be installed, Terminal Server client software must be reinstalled afterward to make use of the raised encryption level.

  • Logon Settings On this tab, the user logon credentials settings can be set. The Terminal Server can log on sessions using a predefined user account, or client-provided logon information can be used. There is a check box to have the server always prompt for a password; this feature adds a level of security.

  • Sessions The configurations set on the Sessions tab, shown in Figure 27.9, allow time limitations to be set for active, disconnected, or idle sessions. Configuring idle and disconnect session time helps to free server resources to keep performance high.

  • Environment On this tab, a session can be configured to run only a single application as opposed to a full desktop session.

  • Remote Control On this tab, remote control options can be configured so that they do not conflict with an organization's privacy policies, while still providing the desired administrative function.

  • Client Settings The Client Settings tab is used to manage which local client resources can be made available within a Terminal Server session to enhance functionality or to secure the environment. For instance, some organizations require that data remain only on local file servers, thus requiring that mapping of local client disk drives and printers be disabled to prevent users from saving data on their remote workstations, or even worse, unknowingly uploading infected files to the Terminal Server network.

  • Network Adapter This tab limits the number of connections a Terminal Server can have and also specifies a single network adapter for a particular Terminal Server connection object.

  • Permissions This tab specifies who can access and/or administer the particular Terminal Server connection object.

Figure 27.9. The Sessions tab configuration settings.

Note

Configurations made in the Terminal Services Configuration snap-in override specified user and client settings.

Group Policy for Terminal Server

Group Policy contains several Terminal Server user and computer settings to configure Terminal Server sessions within Active Directory. A Terminal Server administrator can modify existing group policies or create new group policies to manage Terminal Server configurations on an Active Directory site, domain, or organizational unit level. The individual Terminal Server polices are applied to users individually or based on group membership.

Group Policy is the preferred method of standardizing Terminal Services configurations throughout Active Directory because user and server configurations can be centrally administered. Because so many Terminal Server settings are available in Group Policy, the following list outlines where Terminal Server settings can be found:

  • Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

    Allow Logon Through Terminal Services

    Deny Logon Through Terminal Services

  • Computer Configuration\Administrative Templates\Windows Components\Terminal Services

    Almost all Terminal Server settings can be configured here. Settings here override user or client configurations and also override settings made in the User Configuration section of Group Policy.

  • User Configuration\Administrative Templates\Windows Components\Terminal Services

    User session settings can be configured in this section. Settings here override user or client configurations.

A simple and effective way to manage the GPOs for your Terminal Services servers is to create an OU for your terminal servers and apply GPOs to the OU. Enabling the Computer Configuration\Administrative Templates\System\Group Policy\User Group Policy loopback processing mode is very important if you want the user-context GPO settings to take effect. The loopback processing can be set to either merge or replace. Merging allows existing domain-based GPOs to merge with the ones for Terminal Services, while the replace option overrides all other settings and the Terminal Servicesspecific settings are only applied.

Some additional GPO configuration options that might be useful for your environment include, but aren't limited to, the following:

  • Automatic Reconnection Allows the client to attempt to reconnect to a broken session every 5 seconds for 20 attempts.

  • Restrict Terminal Services users to a single remote session This option improves system performance and can significantly reduce end user confusion by limiting each user to a single session.

  • Encryption and Security section There are many useful configuration settings, such as forcing an encryption level and prompting for a password during a connection.


Installing a Terminal Services License Server

Servers running in Terminal Server mode require a Terminal Services License server to allocate client access licenses. To install a Terminal Services License server, follow these steps:

1. | Log on to the desired server with Local Administrator privileges.
2. | Insert the Windows Server 2003 CD in the CD-ROM drive and close any autorun pop-up windows that open.
3. | Click Start, Control Panel.
4. | Locate and double-click the Add/Remove Programs icon.
5. | Select the Add/Remove Windows Components button.
6. | In the Windows Component Wizard window, scroll down and check Terminal Server Licensing and click Next.
7. | In the Terminal Server Licensing Setup page, choose whether the Terminal Server will allocate licensing for current domain or workgroup or for the entire enterprise if this machine is a member of a Active Directory Forest by selecting the correct radio button.
8. | Note the location of the Terminal Services licensing database, change the location if necessary, and click Next to install the Terminal Services License server.
9. | When the installation is complete, click Finish in the Windows Component Wizard window.
10. | Close the Add/Remove Programs window.

Activating the Terminal Services License Server

A Terminal Services License server can be activated automatically if the server has Internet access, through a Web page from any computer with Internet access, or by the administrator calling a Microsoft Clearinghouse using an 800 number. The License server is activated by contacting the Microsoft Clearinghouse server that will send the Terminal Services server a digital certificate. To activate a Terminal Services License server, follow these steps:

1. | Log on to the desired server with Local Administrator privileges.
2. | Click Start, All Programs, Administrative Tools, Terminal Server Licensing.
3. | Right-click the Terminal Services License server and select Activate Server.
4. | Click Next on the Welcome screen.
5. | Choose the proper connection method and click Next.
6. | If the Web browser or Phone connection method is chosen, follow the instructions in the window to complete Terminal Services licensing activation. Click Finish when done.
7. | If Automatic activation is chosen, enter the appropriate Company information to send to the Microsoft Clearinghouse and click Next at each window.
8. | After the server is activated, uncheck the Start Terminal Server Client Licensing Wizard Now check box and click Next to return to the Terminal Services Licensing console.

The Terminal Services License server should now be activated and ready for installing client access licenses.

Installing Client Access Licenses

After the Terminal Services License server is activated, client access licenses must be installed. Windows 2000 comes with a built-in Terminal Services CAL, so Windows 2000 CALs are already installed. To provide CALs for other operating systems, follow these steps:

1.
Log on to the desired server with Local Administrator privileges.

2.
Click Start, All Programs, Administrative Tools, Terminal Server Licensing.

3.
Right-click the Terminal Services License server and click Install Licenses.

4.
Click Next on the Welcome screen and the Terminal Services Licensing Server screen, and depending on the default connection method, the CAL Installation Wizard will try to connect to the Microsoft activation server.

5.
When the wizard connects to the activation server, choose the license program that the organization participates in and click Next. For example, select Retail, Open, or Select Licensing from Microsoft, as shown in Figure 27.10.

Figure 27.10. Choosing the license option for activation.

[View full size image]

6.
On the Licensing Program page, enter the license number or agreement number for your licensing pack and click Next.

7.
In the Program and License Information page, choose the Windows Server 2003 or Windows 2000 product version; then choose the correct license type as described in the following options:

  • Windows Server 2003 Per User CAL Allocates licenses on a per-user basis.

  • Windows Server 2003 Per Device CAL Allocates licenses to each device that connects to a Terminal Server session.

  • Windows 2000 Per Device CAL Allocates licenses to each device that connects to a Terminal Server session.

  • Windows 2000 Internet Connector CAL Allows nonemployees to connect to the Terminal Server from the Internet.

8.
Enter the quantity of licenses and click Next.

9.
After the licensing information is verified and the CALs are installed, click Finish to close the CAL Installation Wizard.

Now that the licenses are installed, you must configure each Terminal Server to use the correct licensing type.

Configuring the Licensing Type on a Terminal Server

In Windows Server 2003 Terminal Services, there are two methods of licensing. One option is setting the licensing based on a per-device basis, and the other option is setting the licensing on a per-user basis. To set the licensing type of a Terminal Server, follow these steps:

1. | Log on to the Terminal Server with Administrative rights.
2. | Click Start, All Programs, Administrative Tools, Terminal Server Configuration.
3. | Select Server Settings in the left pane.
4. | In the right pane, double-click the Licensing setting.
5. | Under Licensing Mode, choose the correct licensing type, per device or per user, to match the type of client access license purchased.
6. | Click OK to update the Terminal Server.


Installing and Configuring Fault-Tolerant Terminal Services

Terminal Services reliability and performance can be maintained and improved by implementing fault tolerance using Windows Server 2003 network load balancing and/or Windows Server 2003 Session Directory server.

Network Load Balancing Terminal Server

Terminal Servers can be easily scaled out using Windows Server 2003 NLB. Creating NLB clusters to spread server load across multiple Terminal Servers not only increases fault tolerance, but also allows the administrator to take a particular server offline for maintenance without affecting the availability of the Terminal Server environment.

Using NLB clusters along with Windows Server 2003 Session Directory server enables an end user to reconnect to a disconnected Terminal Server session that is currently running on an NLB cluster node. This way, users who want to close a session and return to it later can be assured that they will connect to the same session. Using NLB without Session Directory server could result in a disconnected user creating an entirely new session on a different cluster node when attempting to reconnect to the existing session.

To make a Terminal Server running on Windows Server 2003 part of an NLB cluster, follow these steps:

1.
Log on to the Terminal Server with Administrative rights.

2.
Open the property page of the desired network adapter.

3.
Add the cluster IP address to the network adapter in the Internet Protocol (TCP/IP) Advanced section and click OK twice to return to the network adapter property page.

4.
Check the Network Load Balancing box on the General tab of the network adapter property page.

5.
To make specific changes to the Network Load Balancing settings, click Properties.

6.
Enter the cluster IP address and full Internet name in the Cluster Parameters page, and on the Host Parameters page, enter Priority (unique host identifier) and the dedicated IP address.

7.
On the Port Rules page, configure a port rule to allow port TCP 3389 (RDP) and configure only single or class C affinity filtering mode. Do not use the None filtering mode because Terminal Server sessions will fail.

8.
Disable any unnecessary port ranges by creating additional port rules. Refer to Figure 27.11 for basic Terminal Server port rules. Click Next and then Finish when completed.

Figure 27.11. Choosing port rules for the Terminal Server system.

You need to perform the preceding steps on each server in the cluster, or you can configure all the servers in the cluster at one time by using the Network Load Balancing Manager, which is discussed in Chapter 31, "System-Level Fault tolerance (Clustering/Network Load Balancing)."

Configuring the Session Directory Server

To make use of a Session Directory server, a Terminal Server load-balanced cluster must be built. It can be a Microsoft NLB cluster or a cluster built using a hardware-based loadbalancing device.

Session Directory server service can be run from any Windows Server 2003 Enterprise or Datacenter server. To create a Session Directory server, follow these steps:

1. | Open the Services applet on the server that will be the Session Directory server. The Session Directory server does not need to run a Terminal Services server but needs to be running on a Windows Server 2003 Enterprise or Datacenter server.
2. | Find the Terminal Services Session Directory service and double-click it.
3. | On the General tab, in the section labeled Startup Type, change the startup type to Automatic.
4. | Click Apply to submit the change and click Start to begin the Session Directory service. Click OK to close the service window and close the services console.
5. | After the service is started, each terminal server computer object that will use the Session Directory server must be added to the newly created local group called Session Directory Computers. This task can be performed using the Local Users and Computers applet in Computer Management on a Session Directory Server that is a domain member server, or it can be performed using Active Directory Users and Computers if the Session Directory server is a domain controller.

Now you must configure the nodes in the Terminal Server cluster to use the Session Directory server. On individual nodes in the cluster, use the Terminal Services Configuration snap-in and select the Server Settings section to configure the following settings.

1.
Set the Restrict Each User to One Session setting to Yes.

2.
Enable the next setting, Session Directory, shown in Figure 27.12, by checking the Join Session Directory box.

Figure 27.12. Terminal Services session directory settings.

[View full size image]

3.
Add the fully qualified domain names of the Terminal Server cluster and the Session Directory server.

4.
Choose whether the clients will reconnect to the virtual cluster IP address or the actual dedicated IP address of the server node. Connecting to the virtual cluster IP address is preferred. Leaving this option unchecked is preferred for Windows 2000 and Windows Server 2003 Terminal Server clients.

5.
When you're finished, click OK to return to the Terminal Server Configuration snap-in.


Securing Terminal Services

Terminal Servers should be secured using standard security guidelines and policies defined by the organization. In addition to the organization's security standards and guidelines, it is advisable that organizations use recommended best practices compiled by Microsoft, as well as the National Institute of Standards and Technologies (NIST) and the National Security Agency (NSA). Both NIST and NSA provide security lockdown configuration standards and guidelines that can be downloaded from their Web sites (http://www.nist.gov and http://www.nsa.gov, respectively).

Windows Server 2003 Terminal Services in Terminal Server mode can be run in either the Full Security compatibility mode or Relaxed Security Permission compatibility mode to meet an organization's security policy and application requirements. Permission compatibility mode was created to help lock down the Terminal Server environment to reduce the risk of users mistakenly installing software or inadvertently disabling the Terminal Server by moving directories or deleting Registry keys. This mode can be used for most certified Terminal Server applications. Relaxed Security mode was created to support legacy applications that require extended access into the server system directory and the system Registry.

Changing the RDP Port

As mentioned earlier, Terminal Services securely communicates over TCP port 3389 using RDP. Organizations requiring even greater security can change the default port by modifying the following Registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\
WinStations\RDP-Tcp\PortNumber

Note

Only clients using RDP version 5.1 or greater can connect to the nonstandard port. Also, after the port is changed, the Terminal Server must be restarted.

Perimeter Protection Considerations

If Terminal Services is being accessed through a firewall, there are a few considerations to take into account. Many firewalls are configured to close connections after a specified period of inactivity. This feature, although a good one to employ, may affect Terminal Services by prematurely disconnecting user sessions. In addition, this may unnecessarily use server resources, or worse, it can prevent users from connecting back into the same session.

To mitigate this problem, you can increase the Terminal Services keepalive values or reconfigure the firewall. The keepalive values are located in the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

  • The DWORD "KeepAliveEnable" value should be set to 1

  • The DWORD "KeepAliveInterval" value should be set to 1

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  • The DWORD "KeepAliveInterval" value in milliseconds

  • The DWORD "KeepAliveTime" value in milliseconds

  • The DWORD "TcpMaxDataRetransmissions" numeric value

Next, use the Terminal Services Configuration snap-in and under Sessions, check the Override Users Settings box and choose Disconnect from Session.

Securely Building Terminal Servers

When building security into Terminal Servers, keep in mind that you are giving users certain levels of access to a server. Essentially the users are logging in to the server and using the applications and services installed on that server. With this in mind, it is important to strike a balance between a user's productive capability and what the user can do (intentionally or accidentally) to the server. Otherwise, a single session can significantly affect other user sessions, as well as the entire Terminal Services server.

Segmenting Resources

Terminal Server resources should be segmented in such a way that users can only modify specific settings. This sounds simple, but requires careful planning. For instance, partitioning the server's disk subsystem can keep the operating system, logs, applications, and profiles separated. Each of these partitions should also be formatted with NTFS so that the proper permissions can be applied. This also makes it easier for administrators to manage and lock down specific resources.

The profile partition should be given particular attention because of the nature of the content it stores. For smaller installations, profiles can be stored on the local server on a separate partition. For larger installations, profiles should be kept on a separate server just to hold those profiles. This not only improves security, it can significantly improve performance.

Typically, these temporary Terminal Services profiles are stored under %SystemDrive%\ Documents and Settings\%Username%, even if roaming profiles are used in the network environment. To change the location to another partition, do the following:

1. | Create a Documents and Settings folder on the partition.
2. | Modify HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProfileList\ProfilesDirectory Reg_Sz to the new location.
3. | Restart the server.
4. | Copy over the Default and All Users profiles to the new location.

Securing Terminal Services with GPOs

As mentioned earlier in the "Group Policy for Terminal Server" section, GPOs can and should be used to secure the Terminal Services environment. For instance, if an application or department working with sensitive information uses Terminal Services, the Remote Control setting can be disabled to ensure that only authorized users can view these sessions. GPOs can also be used to set disconnect timeout values and allow reconnections from only the original client.


Sizing and Optimizing Terminal Services Environments

The Terminal Server can be sized to deliver high-performance terminal sessions by estimating the amount of resources each user will require and the number of users who will utilize Terminal Services. Performing frequent performance testing on the Terminal Servers helps generate accurate information on Terminal Server usage. You should perform performance testing during both peak and nonpeak times to ensure proper data collection. Increase memory and processors or introduce additional Terminal Servers as necessary. Understanding the users' resource needs and the number of users will help you decide how to specify the server hardware requirements and determine how many Terminal Servers you need to support the load.

Scaling Terminal Services

Scaling Terminal Services can be achieved by increasing server resources such as the number of processors and the amount of memory, as well as by increasing the number of servers that are servicing requests. When determining how to scale, also consider manageability, cost, and how end users may be affected if a server goes offline. For instance, using a greater number of lower-powered servers may increase manageability (such as updating applications, keeping up with operating system updates, and other maintenance), but if a server goes down, fewer users will be affected. The solution will vary depending upon your organization's needs and circumstances.

Another consideration is the amount of flexibility your organization requires. Using more instead of bigger servers gives more flexibility because of the redundancy, as well as the capability to take servers offline for maintenance. In this scenario, it is important to use servers with enough power to sustain slightly greater workloads during those times when other servers in the farm go offline.

Note

For more information on scaling Terminal Services, refer to Microsoft's "Windows Server 2003 Terminal Server Capacity and Scaling" whitepaper.

Adding Redundancy and Scalability to Session Directory

Using Session Directory server in Terminal Services farms is a great way to provide failover for user sessions. To avoid this service from becoming a single point of failure and scale it to meet the performance needs of the organization, you can configure Session Directory to run as a clustered service using MSCS. To create the cluster for Session Directory, do the following:

1.
Ensure that the Terminal Services Session Directory Server service is set to Automatic.

2.
Ensure that the following resources are available in the server cluster configuration:

  • Physical Disk In addition to the quorum disk, the cluster will require a shared disk for the shared data.

  • IP Address A static IP address that is accessible to all the terminal servers.

  • Network Name A name that is resolvable from all the terminal servers in the cluster. Kerberos is required for all communication between the terminal server and the Session Directory server. Make sure to select Enable Kerberos Authentication and DNS Registrations Must Succeed before bringing the network name resource online.

3.
Select File, New, Resource. When the wizard starts, enter the name and description, and set the resource type to Generic.

4.
Click Next and accept the defaults.

5.
Define your dependencies. Specify the Physical Disk and Network Name resources.

6.
Define the Generic Service Parameters. Specify the service name (TSSDIS) in the Service Name box, and check the box next to Use Network Name for Computer Name.

7.
Configure Registry Replication. Click Add and type System\CurrentControlSet\Services\Tssdis\Parameters.

8.
Click Finish.

9.
Bring the new service resource online.

Note

For more information on MSCS, refer to Chapter 31.

Optimizing Terminal Services Performance

Optimizing Terminal Services is a challenging task because of the complexities in any environment. Hardware resources, applications, usage, the number of users to support, and much more can affect how well Terminal Services responds to users. There are rarely cases where there is one "silver bullet" that can improve overall performance; it takes a combined approach. For instance, from a user perspective, video, color depth, audio redirection, printer redirection, and encryption level all affect how well a system performs.

The following are best practices for ensuring that the Terminal Services implementation runs as efficiently and effectively as possible:

  • Limit users to a single session.

  • Log off disconnected or idle sessions after a specified period of time.

  • Use only Windows Server 2003 certified printer drivers.

  • Use Windows Server 2003 certified applications and consult the vendor for specific application optimizations.

  • Use Microsoft Operations Manager (MOM) or other operations management software to monitor the Terminal Services farm.

  • For medium and enterprise deployments, use a separate server or group of servers with a fast disk subsystem to store user profiles.

  • Consider using third-party Web browser pop-up blockers.

  • Block Internet Web sites that use a lot of animation.

  • Prevent users from installing applications such as games or desktop enhancements/themes.

  • Automate Web browser cookie deletion.

Monitoring Terminal Server

The Performance MMC snap-in can be used to monitor Terminal Services and to gather session statistics. The two specific performance objects for Terminal Services are Terminal Services and Terminal Services Session.

The first object, Terminal Services, has only three counters: active sessions, inactive sessions, and total sessions. Gathering this session data and teaming it with information such as Server Memory\Available Bytes and Processor\% Idle can give an administrator a clear understanding of Terminal Server usage and load. This information can be used to determine whether additional resources or servers need to be added to accommodate load or enhance performance. One adjustment that may be made after taking readings from these counters is the implementation of disconnected session time limits to free server hardware resources for active sessions.

The second performance object, Terminal Services Session, can be used to monitor all counters available for a particular Terminal Server session. This object can be used to get accurate statistical information, such as how much memory and processor time the average Terminal Server session uses. Be sure to monitor network interfaces for available bandwidth to ensure that the Terminal Server is not creating a bottleneck between clients and other back-end servers.

Using Windows System Resource Manager to Control Resources

With Windows System Resource Manager (WSRM), you can limit the amount of CPU and memory an application can use. In the Terminal Services environment, you can assign distinct settings based not only on an application, but on a specific user or group as well. This helps to enforce consistency among user sessions and prevent rogue applications or sessions from negatively affecting other user sessions. For more information on using the Windows Resource Manager, refer to Chapter 35, "Capacity Analysis and Performance Optimization."


Supporting Terminal Services

Supporting Terminal Servers involves more than just proper configuration; it also involves supporting end users, installing and maintaining applications, and securing and optimizing Terminal Server settings, among other server duties.

Using the Terminal Server Manager

The Terminal Server Manager can be used to manage sessions on a Terminal Server. Process and resource usage on the Terminal Server can be monitored here on a server or per-user basis. When an administrator requires remote control access of a terminal session, she must be running in a terminal session and start the remote control function from within Terminal Server Manager. This tool can also be used to send messages to active session users.

Managing the Command-Line Terminal Services

Windows Server 2003 has many new command-line tools to make Terminal Server administrative tasks much more flexible and scriptable. There are nearly 20 different command-line utilities for Terminal Services. For the complete listing, refer to Windows Server 2003 online help; we've listed a few of the utilities that may prove to be most useful:

  • tskill.exe This tool can be used to kill hung or stuck processes or applications in any active session without having to connect to the session using remote control.

  • Shadow.exe This tool initiates a shadow or remote control session from a command prompt or script.

  • Query.exe {Process, Session, Termserver, User} This tool allows the administrator to query a particular server to get a list of current active and inactive sessions and processes.

  • TSShutdn.exe This tool allows an administrator to remotely shut down or reboot a Terminal Server. This tool can notify existing users how long before the shutdown occurs.

Managing Terminal Services Using WMI

Windows Server 2003 has a great new Windows Management Instrumentation (WMI) Provider for Terminal Server management. Administrators can create WMI-based scripts to configure and manage Terminal Servers remotely. The WMI Provider allows an administrator to perform almost every task on a Terminal Server that could have been performed using the command-line tools, Terminal Server Manager, or Terminal Services Configuration snap-in. The general description of classes, properties, and methods available in this WMI Provider refer to the comments within the provider file at %SystemRoot\system32\Wbem\tscfgwmi.mof.

Supporting and Enabling Terminal Server Users

The Windows Server 2003 and XP Professional systems contain a local group called Remote Desktop Users. This group and the Administrators group are allowed to log on using Terminal Services by default. When a Windows Server 2003 server joins a domain, the Domain Users group can be made a member of the local Remote Desktop Users group, giving all domain users the right to log on through Terminal Services if desired.

You can restrict which users can log on using Terminal Services by performing the following:

  • For a standalone implementation of a Terminal Server, add or remove members from the local Remote Desktop Users group to control Terminal Server logon access.

  • For Terminal Servers in a domain, use Group Policy to control logon access by defining the Allow Logon Through Terminal Services setting and add the appropriate groups or users.

When applicable, create a Domain Universal or Global Security group for Terminal Server users and add only this group to the Allow Logon Through Terminal Services setting.

Disabling Terminal Services

To disable Terminal Services, use local security policy or Group Policy, where applicable, to define the Deny Logon Through Terminal Services setting and apply it to the Everyone group, as shown in Figure 27.13.

Figure 27.13. Disabling Terminal Services using Group Policy.

[View full size image]

Note

Defined Group Policy settings for Terminal Services override local security policy settings; they do not complement one another.

Remotely Managing a Terminal Session

Terminal Server users may require support for tasks such as mapping to a file share, installing a third-party print driver, or just troubleshooting issues within the terminal session. While using the remote control features of Terminal Services, an administrator can interact with users in active sessions with view-only access or complete remote control functionality. The amount of access given to an administrator during a remote control session can be set by the user, but it can be configured at the server level by the administrator.

An administrator can remotely control a user's terminal session only from within a separate terminal session. The remote control command can be initiated using Terminal Server Manager or the command-line tool Shadow.exe.

Applying Service Packs and Updates

Applying service packs and updates on a Terminal Server follows the same strategy as outlined in the previous section "Installing Applications for Terminal Server." Test all service packs and updates in an isolated lab environment prior to production release and always create a backup of the system first to allow for rollback, if necessary.

Performing Disaster Recovery on a Terminal Server

Backing up and restoring a Terminal Server follow the same procedures as backing up and restoring a standalone server. Administrators must be sure to back up any local user data, including profiles, and back up the current server system state. The data and system state backup, accompanied with a server build document, are all that an administrator needs to recover the Terminal Server. For detailed steps concerning the creation of server build documents and Windows Server 2003 backup and recovery techniques, refer to Chapter 24, "Documenting a Windows Server 2003 Environment," Chapter 32, "Backing Up a Windows Server 2003 Environment," and Chapter 33, "Recovering from a Disaster."


Accessing a Terminal Server

A Windows Server 2003 Terminal Server can be accessed from a variety of clients. These clients include 32-bit Windows-based clients, 16-bit DOS-based graphic clients, and ActiveX Web-based clients.

Accessing Terminal Services Using the 32-bit Windows RDP Client

All Windows Server 2003 server versions and Windows XP Professional include a 32-bit Terminal Server client called Remote Desktop Connection. This full-featured client enables end users to tune their connections to run in full-screen mode, utilizing advanced features such as server audio redirection, true-color video, and local disk, COM port, and printer redirection. Remote Desktop Connection can also be optimized to run over a 28.8Kbps connection. Down-level client workstations can get the RDP client as a free download from the Microsoft Web site.

Accessing Terminal Services Using the Web Client

Terminal Services provides a Web-based client that can easily be distributed through a Web browser. This client downloads as an ActiveX object and needs to be installed only once. Connecting to a Terminal Server using this client requires a Web port connection to the Terminal Server logon Web page and also access to TCP port 3389 on the Terminal Server. The Web-based client still uses the Remote Desktop Protocol (RDP) native to Windows Server 2003 Terminal Services.

Contrary to many Terminal Server administrators' beliefs, the Web server system hosting the Web client pages does not need to be running on the Terminal Server. If there is no particular reason to run a Web server on the Terminal Server, for security and performance reasons, place the Terminal Server Web client on a separate Web server.

To install the Web server client on a Web server system, do the following:

1. | Click Start and Select Control Panel.
2. | Locate and double-click the Add/Remove Programs icon.
3. | Select the Add/Remove Windows Components button.
4. | Assuming this server does not already have the Application Server running, check the box next to Application Server and click the details button.
5. | Ensure that the Internet Information Services (IIS) box is checked, highlight this option and click the details button.
6. | Scroll down and check the World Wide Web Service box and click the Details button once again.
7. | Check the box next to Remote Desktop Web Connection and press OK three times followed by pressing the Next button to begin the installation.
8. | Once the installation has completed, click Finish and close the Add/Remove Program window. To access this page, open a Web browser and type http://servername/tsweb.

Using the Remote Desktops MMC (Tsmmc.msc)

Remote Desktops is a utility that provides a way to manage several Terminal Services sessions from within one window. This utility still uses the RDP protocol to connect to servers and workstations, but it allows an administrator to switch between terminal sessions by clicking a button instead of having to switch windows. Also, because the console settings can be saved, a new terminal session can also be established with the click of a button.

Remotely Connecting to a Terminal Server Console

Administrators can connect to Terminal Server consoles remotely by using the Remote Desktop Connection client or the Remote Desktops MMC snap-in. With remote console access, administrators can use Terminal Services to log on to the server remotely as though they were logged on at the console.

Using the Remote Desktops MMC snap-in, administrators can configure remote desktop sessions that always connect to the Terminal Server console session shown in Figure 27.14. This enables administrators to successfully install and update the operating system and applications remotely.

Figure 27.14. Setting administrative snap-in settings for console connection.

Caution

You need to know whether to leave the console session logged in and/or locked. If a user logs out of the session, the console will also be logged out. So, you need to be informed and be safe.

To connect to a Terminal Server console using Remote Desktop Connection, run mstsc.exe from the command prompt with the /console switch to gain console access.


Summary

Windows Server 2003 Terminal Services is a flexible tool that can be used to provide administrative and remote user functionality. Depending on the needs of your organization, Terminal Services can be used for remote administration and end user support and to provide full remote desktop functionality. Terminal Services enables users and system administrators alike to perform job functions productively from the office or remotely with simplicity.


Best Practices

  • Avoid installing applications and services from within a Terminal Server session to avoid getting locked out of your Terminal Server sessions.

  • Filter the security event log for user logon and logoff events and review performance logs.

  • Configure each of the Terminal Server nodes in a cluster to restrict each user to one Terminal Services session through Group Policy or in the Terminal Services configuration snap-in.

  • When clustering or load balancing Windows Server 2003 Terminal Servers, use Session Directory server to manage sessions within the Terminal Services cluster.

  • Enable Remote Desktop for Administration mode on all internal servers to allow for remote administration.

  • When choosing an antivirus product, be sure to choose one that is certified to run on Windows Server 2003 Terminal Servers.

  • When a Terminal Server is due for an operating system upgrade, if possible replace the server with a clean build and test all applications, instead of performing in-place upgrades to avoid server or application failures.

  • Place your Terminal Servers where they can be readily accessed by the clients that will primarily be using them.

  • Whenever possible, choose applications that have been tested and certified by Microsoft to run on Windows Server 2003 Terminal Servers.

  • For optimum performance for multitiered applications, install two or more network cards on a Terminal Server and configure the server to use one exclusively for Terminal Server client connectivity and the others for back-end server communication.

  • Use Group Policy to limit client functionality as needed to enhance server security, and if increased network security is a requirement, consider requiring clients to run sessions in 128-bit high encryption mode.


Part VIII: Desktop Administration

In This Part

CHAPTER 28 Windows Server 2003 Administration Tools for Desktops

CHAPTER 29 Group Policy Management for Network Clients


Chapter 28. Windows Server 2003 Administration Tools for Desktops

In This Chapter

  • Examining Desktop Deployment Options

  • Using Remote Installation Services to Deploy System Images

  • Creating Windows XP Images

  • Managing Windows XP Installation Media and Image Versions

  • Updating Existing XP and 2000 Workstations

  • Managing Desktop Applications

  • Managing Windows XP Desktops Remotely

When IT departments talk about Active Directory, they usually think of servers, enterprise back-end application environments, infrastructure, or security. However, one of the hidden gems of Active Directory and Windows 2003 has been its capability to help the administrators of client systems (such as desktop, laptop, and mobile users) better manage and administer client systems from a centralized location and with common network tools. Windows Server 2003 enables administrators of client systems to select the appropriate method of administration to reduce or automate repetitive tasks and to provide task scalability to reduce the overall number of workstation visits or issues.

This chapter covers administrative tools and concepts that can be used to install and manage Microsoft Windows XP Professional workstations. Topics such as deploying desktops and keeping the operating system up to date are covered. Also, remote administration and remote application installation are described in this chapter. Many of the tools and concepts used in this chapter apply to Windows 2000 Professional workstations, but we assume that the desktop OS is Windows XP.


Examining Desktop Deployment Options

When it comes to deploying workstations in a Microsoft Windows networking environment, several options are available. You could load operating systems by starting with boot disks or by starting the installation from across the network using a command-line network client such as MS Client. Some options were adopted by large hardware distributors, but these options were too complicated and required many hours of testing; therefore, they were never adopted by small and medium-sized organizations that did not see the value in complicated installations. Windows 2000 and Windows XP continue to follow Microsoft's record of providing several desktop deployment methods.

Manual Installation

Installing Windows XP or Windows 2000 manually is always an option and probably the most frequently used method of installing the operating system. Many administrators and organizations consider imaging undependable or questionable. As a matter of fact, in previous versions of Windows operating systems, if a machine was installed using imaging software, it was always questionable and sometimes blamed for system corruption. One of the advantages of manual installation is that you always start with the clean base operating system to build upon.

To install Windows XP manually, insert the Windows XP bootable media and start the workstation. You might need to enter a key to boot from the CD, but after that the installation will start. The step-by-step installation instructions on the root drive of the Windows XP CD are clear and easy to follow.

Unattended Installations

A more automated method of installation is the unattended installation. This type of installation is possible because the installation questions are answered automatically using information stored in a setup or answer file.

An advantage of this approach is that the entire installation can be scripted and loaded on a CD. When you boot from this CD, the operating system installation commences. When applications are assigned using Group Policy, the workstation could be up and running automatically within a short time frame. The time to complete the unattended installation is close to the time required for a manual installation, but user error can be reduced and the installation does not need to be watched to keep the installation moving. The only user intervention necessary is starting the system from the bootable CD.

You can customize an unattended installation to support several types of installations and hardware configurations by specifying information in the installation configuration files.

Desktop Imaging

Desktop images are copies of the running workstation in its current state. Only a few software vendors have developed software that has been used successfully to deploy Windows workstations using stored images.

Remote Installation Services

Remote Installation Services (RIS) on Windows Server 2003 can be used to create and deploy Windows 2000 and Windows XP desktop images. Also, starting with Windows Server 2003, server-based images can be created and deployed using RIS. Remote Installation Services takes advantage of a few system preparation tools to enable you to automate and standardize desktop installations across the enterprise. RIS does have some client-side requirements and limitations, but even a basic installation with one image could greatly simplify desktop deployment.

Third-Party Imaging Software

Some of the advantages of using third-party imaging software are that you can compress data and create bootable images that can be split across multiple CDs. Also, the more advanced versions provide one-to-one (Unicast) and many-to-one (Multicast) modes.

Multicast Imaging Software

Multicast technology provides the ability to send compressed and sometimes encrypted data to several clients using only a single stream of information. The technology itself is optimized and requires less network bandwidth than if the same number of clients were accessing the data stream individually. Multicast server and workstation imaging software allows administrators to take advantage of this technology to deploy images to a handful or hundreds of workstations on the local network or across the entire enterprise. The only catch is that each of the multicast clients must remain idle until all the clients have attached and are ready to receive the image. After all the clients are connected, the image can be pushed down on all the workstations simultaneously.


Using Remote Installation Services to Deploy System Images

Windows Server 2003 includes a server and workstation imaging-deployment product called Remote Installation Services (RIS). First introduced in Windows 2000, the RIS deployment tools were somewhat limited and could be used only to deploy Windows 2000 Professional workstations. Starting with Windows Server 2003, server images can also be saved and deployed across the enterprise. This allows administrators to configure both server and desktop standard images to be used across the enterprise. Remote Installation Services is handy, but before you deploy desktops using this product, you should do some testing and planning.

Planning RIS Deployments

Installing RIS on a Windows Server 2003 system is a fairly simple process, but planning how the RIS server will be used can help ensure a successful implementation. Considerations for RIS include deciding how many systems the RIS server should deliver installation images to simultaneously. Also, RIS client computers must support remote boot either with a bootup disk or using pre-boot execution (PXE) on compatible systems. Because RIS servers try to deliver the image to clients as fast as the network can handle, you must limit RIS server access to LAN clients to avoid having the RIS server saturate WAN links while imaging client computers.

Storage is always a big concern for imaging servers, and third-party imaging software stores each image in a separate file, which can take up a lot of storage space. Although these image files often compress fairly well, RIS stores images in their native file formats and replaces duplicate files with file pointers or links to save storage space. The technology used to optimize storage space by recognizing files used in different images is Single Instance Storage (SIS). SIS works by replacing actual duplicate files with junction points within the RIS image storage locations. This reduces the overall storage requirements of the RIS server, allowing for the creation of several custom images, including saving user desktop images to the RIS server as a means of recovery. To optimize performance, you should install RIS and RIS images on separate physical disks than the operating system to improve system image access.

Installing RIS

An administrator with Local Administrator access can quickly install RIS. The RIS server must also be part of an Active Directory domain, and a DHCP server must be available on the network. To install RIS, perform the following steps:

1. | Log on to the RIS server using an account with at least Local if not Domain Administrator access.
2. | Choose Start, Control Panel.
3. | Select Add/Remove Programs.
4. | Select Add/Remove Windows Components.
5. | Scroll down the list and check Remote Installation Services.
6. | Click Next to install RIS and click Finish after the installation is complete.
7. | Close the remaining open windows and reboot the server as instructed.

Configuring RIS

After the RIS server reboots, the service can be configured. Upon the initial configuration, you need to specify the storage location of the RIS server and choose some simple installation options. Also, during this process, the first installation image is created. This image is based on a clean OS installation of the particular operating system version. For example, a Windows 2000 Professional CD could be used for the first image on a Windows Server 2003 RIS server. To configure RIS, follow these steps:

1.
Log on to the RIS server using an account with at least Local if not Domain Administrator access.

2.
Choose Start, All Programs, Administrative Tools, Remote Installation Services Setup.

3.
Read the information on the RIS Wizard welcome screen to ensure that the RIS requirements will be met for a successful implementation. Then click Next to continue.

4.
In the next window, specify the local path where the RIS images will be stored. The folder cannot be on the system drive and must support enough space to store all the images. The installation path cannot be on the boot partition or the partition with the operating system loaded on it. After you specify the folder location, click Next to continue.

5.
The initial settings window allows the RIS server to begin responding to client requests immediately. This option is disabled by default, but to allow the RIS server to start accepting client connections, check the Respond to Client Computers Requesting Service box and click Next to continue.

6.
Now you must specify the location of the first image source files. This information will be used to create the first image on the server. If you're using a Windows CD, specify either the root of the CD or specify the I386 directory of the CD for Intel-based system installations.

7.
In the next window, you specify the image folder location. The default is the name of the systemroot folder of the particular operating system, such as WINNT or WINDOWS. Click Next to continue. In the next window, type in a Friendly Descriptive name and any Help Text for the image folder and click Next to continue.

8.
In the last window, review the specified settings, as shown in Figure 28.1, and click Finish to create the image.

Figure 28.1. Creating an RIS image.

[View full size image]

After you click Finish, the RIS installation finishes and copies the first image installation files to the server. During this process, the unattended answer file must be created to allow the RIS server to automate part, if not all, of the installation. After this process is complete, you need to add two DHCP server scope options for clients to locate the RIS server.

Configuring DHCP for RIS Clients

After you complete the RIS server installation, you must add two DHCP scope options for clients to locate the RIS server. These settings include option numbers 066 and 067; these options are the boot server hostname and the bootfile name. The boot server hostname value is a fully qualified DNS name, and the bootfile name is simply Startrom.exe. To add these options, perform the following steps:

1. | Log on to the DHCP server with Domain Administrator access.
2. | Choose Start, All Programs, Administrative Tools, DHCP.
3. | Expand the Local DHCP Server entry and select the appropriate scope.
4. | Expand the scope and select Scope Options. If multiple scopes are used on this DHCP server and the RIS options need to be added to all scopes, select Scope Options to hold the objects.
5. | Right-click Scope Options and select Configure Options.
6. | Scroll down in the Available Options window to number 066, check the option named Boot Server Host Name, and enter the fully qualified domain name of the RIS server.
7. | Scroll down and check the next setting, 067 Bootfile Name, and enter RemoteInstall\Admin\I386\Startrom.com to complete the DHCP updates for RIS. Click OK to close the Scope options.

Establishing Client Requirements

For a remote client to access an RIS server, it must be able to access the network before it can locate the RIS server. RIS servers require client computers to support preboot execution (PXE) or network boot. Many workstations have this option, but you might need to enable this option or choose it at bootup before it can be used. For client workstations that do not support it, you can use the Remote Boot Floppy Generator (Rbfg.exe) to create a network boot floppy disk. Rbfg.exe is loaded on an RIS server and can be accessed in the %systemroot%\System32\Reminst folder. To create a boot disk, perform the following steps:

1.
Log in to the RIS server using an account with Administrator access.

2.
Insert a blank formatted floppy in the RIS server's floppy drive.

3.
Open Windows Explorer and browse to the c:\windows\system32\reminst folder to locate the Rbfg.exe file. If the file is not there, either this is not the RIS server or RIS has not yet been installed. If RIS has not been installed, skip to the "Installing RIS" section and complete the steps there before returning here.

4.
When the Microsoft Windows Remote Boot Disk Generator opens, click the Create Disk button to create a boot floppy. As the boot floppy is being created, you'll see something similar to what is shown in Figure 28.2.

Figure 28.2. Creating a boot disk for RIS.

If the correct adapter is not on the list, you must create a boot disk in a different way. Search the network interface card (NIC) manufacturer's documentation and Web site for driver details. What you need is a TCP/IP DOS-based driver that can use DHCP to get network configuration and execute a remote file on the RIS server to start the image selection process.


Creating Windows XP Images

If you plan to use RIS or third-party imaging software to deploy Windows XP desktop images, you must take some steps to ensure that the images are created as problem free as possible. Depending on an organization's goals of deploying a new desktop image or the goals of creating standard builds and deploying, using desktop imaging software may be very different between organizations, but the following sections cover steps that you should take for image creation regardless of the project goals.

Installing Desktop Software

Unless you're creating an RIS image using only the Setup Manager Wizard and the installation media for a vanilla installation, you must install Windows XP and any additional updates and applications on a workstation. First, the operating system must be installed and patched to the latest service pack and post service pack release. This helps ensure operating system reliability and security by raising the installation to the latest build and locking down the known vulnerabilities.

After you update the OS, you should install and update Microsoft and third-party applications to the latest patch level. If necessary, open the applications to verify that all the installation steps have been completed, such as registering, customizing, or activating the software.

Standardizing the Desktop

After the operating system and application software are successfully installed and configured, the desktop settings can be customized to meet your organization's particular deployment needs. During this phase, you might enable or configure Windows XP programs such as Remote Desktop, Remote Assistance, or Automatic Update. If roaming user profiles are not used in your organization, you should configure the desktop settings, including screen resolution, desktop shortcuts, and Start menu options. After the desktop is configured, using the Administrator account, you can copy the user profile used to create the settings to the C:\Documents and Settings\Default User folder, assuming that the XP installation is on the C: drive.

Note

The Windows 2003 Resource Kit includes a utility called Delprof.exe that allows a network administrator to delete the profile of a network user. This tool can come in handy for an administrator who wants to clear off disk space on a system full of profiles, or the tool can be used to minimize the risk of profile-related information being compromised from a security perspective. The Windows 2003 Resource Kit is a free download for all network administrators that have legal licenses to Windows 2003. The add-on is available at http://www.microsoft.com/windowsserver2003/downloads/tools/default.mspx.

After the profile is configured, specific user rights should be configured using settings in the local security policy or through Group Policy settings. Local security and Group Policies are covered in detail in Chapter 15, "Security Policies and Tools," Chapter 21, "Windows Server 2003 Group Policies," and Chapter 29, "Group Policy Management for Network Clients."

Minimizing Common Image Errors

Often when administrators prepare a desktop image, many annoying problems are discovered after the image is deployed to the enterprise. For example, left-over mapped drives or local printers or application install points that exist only in the imaging lab remain in the Registry and cause confusion when an application needs to be updated or uninstalled. Something as small as leaving a window open while logging off the workstation before the user profile is updated to the default user profile can prove to be very annoying or look unprofessional after image deployment. To prevent the little problems that may have the end users, clients, or management personnel viewing your image deployment as a failure, be sure to deploy the images to a few pilot users who will be meticulous enough to alert you of these problems before the entire user base has to experience them.

Using the Windows XP Deployment Tools

Windows XP provides a few tools to simplify the desktop installation process by automating installation tasks. These tools are used to clear basic operating system configurations to create a generic image that can be used to deploy the Windows XP operating system.

To start, you should open installed applications, test their functionality, and configure the default user and all user profiles. Also, you should configure and optimize the OS and applications if you have not done that yet. After you configure and successfully test the desktop, you can use the Windows XP deployment tools to remove any unique operating system information and automate installations by creating information files used to answer installation questions.

Setup Manager

The Setup Manager (setupmgr.exe) utility simplifies deployment of Windows XP desktops by using a wizard to create scripts that simplify the imaging of the operating system. Setup Manager performs the following tasks when you choose a specific deployment method:

  • Windows Unattended Installation Setup Manager can create an answer file called Unattend.txt to automate the desktop deployment, but it can also create the software distribution point if the CD is available and a destination path is specified.

  • SysPrep Install This choice creates an answer file called sysprep.inf to be used for images configured to run the MiniSetup Wizard specified when sysprep.exe was run on the workstation.

  • Remote Installation Services Setup Manager can be used not only to create the answer file Remboot.sif but also to create the image on the RIS Server from the CD. This means that you can get a basic image to the RIS server without ever installing Windows XP.

System Preparation Tool

The System Preparation Tool, Sysprep.exe, is a bit different from the Setup Manager, which automates installation by answering installation questions, in that it is used on existing workstations to remove user-specific data such as registered software owner, network settings, and product key information. Using this file before imaging an existing workstation allows images to be customized after installation. This makes the image much more functional and flexible on how and where it can be installed.

To prepare a system for imaging, follow these steps to run sysprep.exe:

1.
Log on to the Windows XP Professional workstation using an account with Administrator access.

2.
To find sysprep.exe, insert the Windows XP CD, browse to the support folder, and locate the Deploy.CAB file. Extract all the files, one of which is sysprep.exe. Then double-click the sysprep.exe utility to start the process.

3.
When sysprep.exe opens, a message states that some security modifications may be executed on the system. After you read and understand the security statements, click OK to continue. After a few moments, you will be prompted to shut down the system.

4.
On the bottom of the page, change the Shutdown option to Quit, as shown in Figure 28.3.

Figure 28.3. Configuring the sysprep.exe settings.

5.
Click the Reseal button to have SysPrep prepare the workstation for imaging.

Note

Selecting to reseal a workstation and run MiniSetup deletes specific workstation configurations such as machine name, domain membership, and network configurations. Select the MiniSetup and Reseal options only on machines built to be used as template image systems.

6.
A warning window appears stating that the computer SID will be regenerated after system shutdown. Click OK to complete the SysPrep process.

Installing the Windows XP Deployment Tools

The Windows XP deployment tools are included on the Windows XP installation media. The deployment tools are stored within a file called Deploy.CAB. This file is located on the Windows XP CD in the Support\Tools directory off the root of the Windows XP media. Simply extracting this file to a specified folder location gives an administrator access to the deployment tools and the supporting documentation.

Creating a Custom Desktop Image for RIS

When an RIS server is set up for the first time, a vanilla image can be created for Windows 2000 Professional, Windows XP Professional, or Windows Server 2003. Often images need to be deployed with software already installed and configurations already performed. When this is necessary, the image must be created using an existing preconfigured system from which to create the image. To avoid naming and IP address conflicts, you must first prepare the workstation for imaging using sysprep.exe. This utility "reseals" the system. This allows a single preconfigured image to be deployed out to different hardware; you also can create individual system names with a unique network configuration.

If you want to create a customized image of a compatible Windows system, the CD image must already exist on the RIS server. The system is ready to upload the image to the RIS server. To perform this task, use a utility called Riprep.exe. This file is located in the RemoteInstall\Admin\I386 folder on the RIS server. After you locate the file, copy it down to the machine you are imaging as follows:

1. | Log on to the system you are imaging and run the Riprep.exe utility.
2. | When Riprep opens, click Next in the Welcome screen.
3. | On the next page, specify the hostname or DNS name of the RIS imaging server and click next. On the next page, specify the folder to copy the image to and then click Next.
4. | Type in a Friendly Description and any Help Text (optional) and then click Next.
5. | Stop any services listed in the following window by clicking Next. If any errors occur, review the riprep.log for details.
6. | Review the Settings summary screen and then click Next and Next again to continue.
7. | After the Riprep process is complete, click Finish.

When the SysPrep process is complete, the system is ready to upload the image to the RIS server. To perform this task, use a utility called Riprep.exe. This file is located in the RemoteInstall\Admin\I386 folder on the RIS server. After you locate the file, copy it down to the machine you are imaging as follows:

1. | Log on to the system you are imaging and run the Riprep.exe utility.
2. | When Riprep opens, click Next in the Welcome screen.
3. | On the next page, specify the hostname or DNS name of the RIS imaging server.
4. | After the Riprep process is complete, click Finish.

Creating an Unattended Installation

When Windows XP is to be deployed unattended or fully automated, you can use the Setup Manager utility to help automate the installation. To create an image using the unattended installation process, follow these steps:

1. | Log on to the Windows XP Professional workstation using an account with Administrator access.
2. | To find setupmgr.exe, insert the Windows XP CD, browse to the support folder, and locate the Deploy.CAB file. Extract all the files, one of which is setupmgr.exe. Then double-click the setupmgr.exe utility to start the process.
3. | When setupmgr.exe opens, click Next on the welcome screen.
4. | Select the option to create a new answer file and click Next to continue.
5. | Select the option to create a Windows unattended installation and click Next.
6. | Choose the correct operating system in the Platform section and click Next.
7. | Choose the user interaction level, which asks how much the user will be able to configure during the installation. For most deployments, choose Provide Defaults or Hide Pages Often. These options either show all the installation settings but the values that are already populated, or installation pages that are completely configured are hidden from the system installation process.
8. | Click Next to continue and then click Next again to create a new distribution folder.
9. | On the next page, you specify whether the installation files will be copied from CD or from the network. Select the appropriate location and click Next when ready.
10. | Select the local path indicating where to store the installation files and what the share name will be. Click Next to continue.
11. | On the following screens, answer the appropriate installation questions and click Next until you have answered or skipped all the settings.
12. | After you've either skipped or configured all the settings, click Finish.
13. | On the next window, specify the location of unattend.txt, which will be used to transfer the information you just copied when an installation is started.
14. | Click OK to save unattend.txt and copy the files to the specified storage location.

Note

You prepare a system for imaging Windows XP with third-party image software the same as you prepare a system using sysprep.exe. You can simply configure the system as you want it and run the sysprep.exe tool to prepare the system for imaging. If you need to create the image to save a user's desktop system to an image, skipping sysprep.exe is the right thing to do.


Managing Windows XP Installation Media and Image Versions

When it comes to updating installation media, administrators sometimes choose not to update the CD or the I386 directory on the servers. This can become an issue when a restore is necessary because a lack of core installation files can prevent the successful installation of new server components or add-ins to the server. If your organization has the Windows media copied to an I386 subdirectory on the server and you perform a service pack update, make sure to slipstream the service pack's latest file updates to the I386 subdirectory on the system so that the server-stored files are the same as the versions of the files loaded on the system. Service packs can be run with an -S switch, which slipstreams the necessary updated files to the server. Hotfixes cannot be updated on the installation media, so you can wait until the machine is installed and send the hotfixes down the wire.

Updating Desktop Images

Whether you create images using RIS or third-party imaging products, when post-installation procedures begin to be excessive or time-consuming, it may be time to update existing stored images. When Microsoft provides operating system service packs, it incorporates most of the fixes within the new service packs. During service pack installation, these previous fixes may be uninstalled automatically or the files may simply be overwritten. When this happens, it is possible to have both the service pack and all the original post service pack releases in the Add/Remove Programs listing. In the end, you can simplify troubleshooting operating system issues if only the original operating system installation and the well-tested service pack are installed.

The same principle should be followed when desktop applications have major release updates. A new image should be created with the latest patched applications to deliver the most reliable desktops.

To know when to update desktop images, follow these few simple rules:

  • Update images when the operating system has a new major release such as a service pack or if a new version is available.

  • Update images when desktop application software vendors release a major upgrade or software revision.

  • Update images when post-deployment tasks that can be automated extend the time necessary to complete desktop deployment.

  • Update images when hardware platforms change enough to require manual driver installations.

Following these few simple rules will help you manage desktop images to reduce administrative overhead.


Updating Existing XP and 2000 Workstations

When imaged desktops undergo a configuration change, make sure to update the image that will be used on all future system configuration builds. As administrator, you can manually install these updates on the workstations using local console or remote console software such as Windows XP Remote Desktop. You can also automate the updates by using scripts that leverage command-line installation options or by creating Microsoft installer packages and deploying the application using Group Policy.

Deploying Service Packs

Microsoft provides several ways for administrators to deploy a new platform service pack to the enterprise. The service pack can be installed manually using either local or remote control software. Also, because service packs come with an MSI package, the service pack can be deployed using Group Policies. Lastly, service packs can be run from a command prompt with special switches to make the installation run silently, without prompts or notifications, if necessary.

Deploying Hotfixes and Security Updates

Hotfixes can be installed manually and individually, but they usually do not provide many more deployment options. Hotfixes can be deployed to the enterprise using the built-in command-line switches called from within computer startup or shutdown scripts in Group Policy. To simplify the installation of several Microsoft hotfixes and/or security updates, you can use a tool called Qchains.exe to install all the updates at one time to reduce the number of required reboots.

Using Windows Automatic Update for System Updates

Auto Update has an option to let the server automatically locate, download, and install the latest operating system updates for a system. If the IT staff members want a more automated approach to IT management, they may choose to enable Auto Update so that it can automatically manage updates to the systems on the network. This is good for organizations to ensure that security updates are installed on all workstations.

The one issue with Auto Update is that if a security patch causes more problems on the system, it may need to be rolled back on several workstations. As a best practice, updates should be reviewed and tested before an automatic installation is performed on multiple systems. Install and test Auto Update on a single workstation to download updates and test the configuration to make sure it successfully accepted the updates. When testing is completed and the results are successful, the updates can be deployed manually, scripted using command-line switches, or packaged into Microsoft Installer software packages deployed using Group Policy.

Choosing to Use Software Update Services for System Updates

Software Update Services (SUS) is a server option on Windows Server 2003 that enables organizations to control which updates are automatically downloaded and installed on the client workstation. SUS runs on a Windows Server 2003 (or Windows 2000) machine that is running Internet Information Services. Clients connect to a central intranet SUS server for all their security patches and updates.

SUS is not considered a replacement technology for existing software deployment solutions such as Systems Management Server (SMS) because it is limited to providing only operating system updates, not service packs or other software packages. SUS allows organizations to take control over the deployment of security patches as they become available. To learn more about SUS, refer to Chapter 12, "Server-Level Security."


Managing Desktop Applications

When managing desktops is the task at hand, finding a way to deploy the operating system and keep it up to date is just part of the necessary administration. Another equally important aspect of desktop management is managing the applications installed on the client workstations.

There are three main aspects of desktop application management: installing or deploying the application, configuring it, and updating it. Windows Server 2003 provides a few different ways to perform these tasks, and the IT staff can use the tools and services available on the Windows XP desktops and the software installation services offered in Group Policy to perform application management tasks on a per-workstation basis, or the tasks can be scaled up to manage the applications for a particular group of users or computers. The following list describes how Windows XP and Active Directory can be used to manage applications:

  • Application installation Applications can be installed on desktops using the software installation services provided in Active Directory Group Policy. Other methods include deploying the application using computer startup/shutdown scripts or user logon/logoff scripts. Lastly, applications can be installed manually either by visiting the workstation and using the local console or using remote control software such as Remote Desktop on Windows XP and Windows Server 2003 systems.

  • Application configuration Depending on the application that needs to be managed, Group Policy templates can be used to configure it. Most built-in Windows services and applications can be configured using Group Policy. For the rest of the application, per-system or even per-user configuration can be set using Group Policy to deploy new Registry keys or update existing Registry key values to provide the configuration. Also, user login scripts can be used to configure application settings.

  • Application updating Application updates can be installed using Group Policy or can be installed manually. Many software vendors provide several ways to deploy application updates using the tools available in Windows and Active Directory or using custom application management utilities. Refer to the release notes and readme files of your particular application to determine how it can be managed.

Managing Applications Using Group Policy

You can manage applications rather easily using Group Policy if you use the right tools. Applications can be deployed using the software installation services function of an Active Directory Group Policy. Applications can also be deployed from a command prompt using a computer or user-based script.

Group Policy Software Installation

Deploying applications using the software installation services of Group Policy requires that the applications are packaged using a Windows Installer Package file (*.MSI). When you're deploying applications to users, the package can be assigned to a user or the pack can be published. When you're deploying applications to computers, the application can only be assigned, not published.

Assigned applications are installed automatically when the policy is applied to the computer or user. For users, published applications are listed in the Control Panel's Add/Remove Programs applet. If an application is published to a user, she need only open the Add/Remove Programs applet and double-click the application for it to be automatically installed. Depending on how the administrator configures the application when defining the application deployment properties in Group Policy, the application can be deployed using elevated privileges and can be customized using Transform files, which are used to specify installation criteria normally answered during a manual installation.

The next example is creating a software installation package to publish the Windows 2003 Administration pack to all users in the Help Desk Security group in the domain. To do so, follow these steps:

1.
Log on to a server with the Windows Server 2003 Administrative tools installed. Log in with an account that has the rights to upload files to a specific share folder and also has the rights to update the necessary Group Policy Object.

2.
Insert the Windows Server 2003 media and browse the media until you locate the AdminPak.MSI file in the I386 directory.

3.
Copy the Adminpak.MSI file to the network share location from where the installation will be pushed down. For this example, use \\Server7\software.

4.
Choose Start, All Programs, Administrative Tools, Active Directory Users and Computers. If you cannot locate the correct console, open MMC.exe from the Start menu's Run prompt and add the snap-in as necessary.

5.
Select the domain, right-click it, and select Properties.

6.
Select the Group Policy tab and then select the correct policy from the list. Because the domain policy does not apply to the Administrators group, best practice is to create a separate policy for settings that will apply to administrators who have other group memberships.

7.
Click the Properties button to open the Group Policy property pages.

8.
Select the Security tab and click Add. Type in the name of the Help Desk group and click OK.

9.
Select the Help Desk group from the security list and click the Allow button for the Apply Policy permission.

10.
Click OK to update the policy security.

11.
Back in the domain's Group Policy property page, select the policy and click the Edit button to open it.

12.
In the policy, expand the Computer Configuration section and select Software Settings.

13.
Expand Software Settings, right-click the Software Installation icon, and select New Package.

14.
Browse to the location of the MSI file, select it, and click Open.

15.
Because this package is being applied to Computer Configuration, select either the Assigned or Advanced option, as shown in Figure 28.4. If you choose the Assigned option, you can modify the Advanced properties later by selecting the package and changing settings on the package's property pages.

Figure 28.4. Selecting the software package deployment options.

Using Third-Party Application Packaging Software

For you to be able to use Group Policy software installation services, the application must be available for installation in a Windows Installer Package file. Many software vendors provide an installer file with the software, but for legacy applications the administrator must create the package file. Several third-party application packaging products are available. To find a list of packaging software, perform an Internet search and look for "MSI packager" or "Windows installer packager."

Manually Installing Applications

When legacy applications cannot be packaged or when a particular application just needs to be installed on a handful of workstations, it may make the most sense to deploy these applications manually. Windows Server 2003 and Windows XP provide several ways for this task to be accomplished. As always, the administrator can install the application from the local system console, but that, of course, requires a visit to the workstation. To access the local console remotely to install applications, the administrator could use Remote Desktop to perform the operation individually or Remote Assistance if the connection is authorized by the end user.

Remote Installation Using Remote Desktop

To install applications remotely using Remote Desktop, the administrator needs to have Administrator group membership on the system. When the connection is made to an XP workstation, the logged-on user is logged out, so this option should be used only if the end user is notified beforehand so that he can save his data. To connect to an XP workstation using Remote Desktop, you simply open the remote desktop connection from the All Programs, Accessories, Communication menu, type in the fully qualified system name of the computer, and click Connect.

Remote Installation Using Remote Assistance

Using Remote Assistance, an administrator can aid an end user who needs to install software on her workstation but does not have the necessary rights. For example, the end user may need to install PDA software on her workstation. When this is the case, she can request remote assistance from the administrator. When the administrator connects, if the proper Remote Assistance settings are configured either in Group Policy or on the local workstation, he can take control of the console. The administrator can then open the Add/Remove Program applet from the Control Panel using the Run As option to specify an account with administrative privileges, which he can then use to install the software without requiring the user to log off.


Managing Windows XP Desktops Remotely

For administrative tasks to be performed on a workstation, such as installing new hardware or configuring user profile settings that are not configured using Group Policy settings, administrators can use the tools provided with Windows Server 2003 and Windows XP. Remote Desktop can be used not only to install software remotely, but also to configure just about everything that could be performed from the local console. The only limitation is that the BIOS settings cannot be controlled. Consequently, if a remote reboot is performed, and the BIOS is configured to first boot from a floppy disk, the system may never restart if a disk is in the drive. In this case, a visit to the workstation will be required.

Starting with Windows Server 2003 and Windows XP, the Computer Management console can be used to perform several system-related software and hardware tasks remotely. New features include adding new hardware by scanning for hardware changes, adding local user accounts and local shares, and manipulating system services. This tool is very flexible for remote administration.

Using the Remote Control Add-on for Active Directory Users and Computers

A significant add-on to Windows 2003 for client system administrators is the Remote Control Add-on for Active Directory Users and Computers. This tool provides an administrator the capability to right-click on a computer account in the Active Directory MMC and choose to remotely administer the system. The tool effectively launches a Terminal Services/Remote Desktop connection to the system.

The Remote Control Add-on for Active Directory Users and Computers is freely downloadable to all network administrators with legal licenses to Windows 2003. The add-on is available at http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx.

Using the Remote Desktop Connection for Windows 2003

Another tool that provides remote control access to client systems and servers is the Remote Desktop Connection tool that comes with Windows 2003 server and Windows XP workstations, or is free to download. Unlike the Remote Control Add-on for Active Directory Users and Computers, which requires launching the Active Directory Users and Computers MMC, the Remote Desktop Connection tool can be launched independently.

Once launched, a network administrator can remotely access and control any desktop or server that has Remote Desktop or Terminal Services enabled.

The Remote Desktop Connection for Windows 2003 is free to download for all network administrators with legal licenses to Windows 2003. The add-on is available at http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx.


Summary

When it comes to desktop management in a Windows Server 2003 Active Directory environment, Microsoft has provided several administrative tools and options to simplify and scale these tasks. Using the Windows Server 2003 tools, along with the services included with a workstation platform such as Windows XP, gives administrators several options for desktop management that can completely remove the need to physically visit a workstation for anything other than deploying the initial workstation image.


Best Practices

  • Install Remote Installation Services images on separate physical disks than the operating system to improve imaging performance.

  • Make sure that the operating system is installed and patched to the latest service pack and post service pack release when creating desktop images.

  • Use Sysprep before imaging an existing workstation.

  • Select the MiniSetup and Reseal options only on machines built to be used as a template image system.

  • Update images when the operating system has a new major release such as a service pack or if a new version is available.

  • Update images when desktop application software vendors release a major upgrade or software revision.

  • Update images when post-deployment tasks that can be automated extend the time necessary to complete desktop deployment.

  • Update images when hardware platforms change enough to require manual driver installations.

  • Use Qchains.exe to simplify the installation of several Microsoft hotfixes and/or security updates and install all the updates at one time to reduce the number of required reboots.

  • Review and test updates before performing an automatic installation on multiple systems.


Chapter 29. Group Policy Management for Network Clients

In This Chapter

  • Leveraging the Power of Group Policy

  • Baseline Administration for Group Policy Deployment

  • General Recommendations for Managing Clients Through Group Policy

  • Using Group Policy for System Updates and Patch Management

  • Real-Life Scenarios of Group Policy Management

Organizations that leverage the capabilities of Group Policy in Windows 2003 have realized the true potential of using policies to manage desktops and mobile users, improve network security, implement patch management routines, and perform regular maintenance tasks throughout the enterprise. By mirroring user data on servers, preventing users from loading unauthorized software, and backing up the entire state of desktops and configurations (profiles) to servers, you can secure, protect, and highly customize your workstation environment.

Furthermore, by applying system standards through group policy to particular users, groups, or sites within Active Directory, you can accommodate the diverse needs present in your organization. Different groups and individuals within any business require varying levels of access and control of your network resources. You should leverage the Group Policy management tools in such a way as to provide the specific workstation experience appropriate to the varying functional needs in your company.

This chapter concentrates on ways you can apply Group Policy tools to users and groups based on their specific needs and goals. In addition to providing general best practices, this chapter provides recommendations on how to handle particular types of network users through Group Policy.


Leveraging the Power of Group Policy

Group Policy functionality is used to deliver a standard set of security, controls, rules, and options to a user and workstation when authenticating to the domain. In addition, it can be used to configure everything from login scripts and folder redirection to enabling desktop features and preventing users from installing software on network workstations. With Windows Server 2003 and applications like Microsoft Office, Group Policy can be used to control the preferences and options available when configuring and customizing the application.

This section helps network administrators understand Group Policy and its functionality and characteristics when they manage the enforcement of policies.

Managing Group Policy

To manage Group Policy, administrators must understand that Group Policy applies only to Windows 2000 client systems, Windows XP client systems, Windows 2000 server systems, and Windows Server 2003 server systems.

To access and manage Windows Group Policy, administrators can use the Group Policy snap-in available in the Administrative Tools program group of the Windows domain controller. Another more powerful option for managing Group Policy with Windows Server 2003 is the use of the Group Policy Management Console (GPMC) tool, described in detail in Chapter 21, "Windows Server 2003 Group Policies."

With the basic Group Policy Management snap-in, administrators are provided with a standard management console through the built-in administrative tools of Windows server. Through the standard method of accessing Group Policy, administrators are provided a single interface to access, manage, and configure policies with the standard options and functionality available in the built-in Windows tools.

Using the Group Policy Management Console tool, administrators are provided with easier access and better management capabilities of Group Policy that extend beyond the standard options available with the Administrative Tools built-in Management snap-in. GPMC also provides enhanced functionality and options for planning and testing Group Policy implementations prior to deploying and enforcing them on the Windows domain.

Note

To manage Group Policy using the GPMC tool in a Windows 2000 domain, the GPMC must be installed on a Windows XP desktop on the domain being managed.

The GPMC must be installed on Windows Server 2003 or Windows XP. The GPMC.msi package can be downloaded from http://www.microsoft.com/Windowsserver2003/downloads/featurepacks. After it is installed, it can be found in the Start menu in the Administrative Tools program group by selecting the Group Policy Management option.

Caution

Because Group Policy can have a tremendous impact on users, any Group Policy implementation should be tested with the Resultant Set of Policies tool in Planning mode. See the "Working with Resultant Set of Policies" section to learn more about testing Group Policy and using the Group Policy Management tool in Simulation mode.

Understanding Policies and Preferences

When working with Group Policy, you have two methods for making changes on the local workstations: using preferences and using policies. With both preferences and policies, changes are applied and enforced using the local Registry of the machine where they are being applied.

With preferences, changes to options such as wallpaper or screensavers and software settings are applied locally. With policies, changes to the Registry are applied that affect security and Registry keys, which are protected by Access Control Lists (ACLs).

Although Group Policy overrides preference settings when working with applications, the policy does not overwrite the preference keys when preferences are set on the local system by the workstation users. This means that if a policy is created, configured, and applied and then the policy is removed, the preferences that were set by the local user before the policy was applied will return.

This makes policies a powerful tool when a network's administrator wants to control certain aspects of a client application or wants something the user accesses to remain static. Policies can be used to disable end users from changing the appearance, configuration, or functionality of the item to which the policy was applied.

Group Policy and Security Templates

One of the most important features for minimizing administration when working with Group Policy is leveraging security templates. Security templates are a powerful predefined set of security options available from Microsoft for applying Group Policy to a specific area or software component available to users on the network. Based on the type of users and environment needed, these templates can be a handy tool to create and enforce configuration settings on components already predefined in the template.

Available with the standard installation of Windows Server 2000 and Windows Server 2003, these templates can be downloaded and imported into Group Policy Objects (GPOs) where they can then either be implemented as is, or modified to meet the specific needs of the area in which the template applies. However, when templates are used, they are a great starting point for network administrators to obtain a base-level configuration of a client workstation's software component or security settings.

Templates can also be used to configure settings such as account policies, event log settings, local policies, Registry permissions, file and folder permissions, and Exchange Server 2003 client settings.

Defining the Order of Application

When applying Group Policy, each policy object is applied in a specific order. Computers and users whose accounts are lower in the AD tree may inherit policies applied at different levels within the Active Directory. Policies should be applied to objects in the AD in the following order:

1. | Local security policy
2. | Site GPOs
3. | Domain GPOs
4. | OU GPOs
5. | Nested OU GPOs and on down until the OU at which the computer or user is a member is reached

If multiple GPOs are applied to a specific AD objectsuch as a site or OUthey are applied in the reverse order from which they are listed. This means that the last GPO listed is applied first and if conflicts exist, settings in higher GPOs override those in lower ones.

Group Policy Refresh Intervals

When Group Policy is applied, the policy is refreshed and enforced at regularly scheduled intervals after a computer has been booted and a user has logged onto the domain. By default, Group Policy is refreshed every 90 minutes on workstation and member servers within the domain.

When you need to better control the refresh interval of a group policy, the refresh interval can be configured for each group policy by changing its time in the policy configuration. Using the GPMC, refresh intervals can be configured by going to domain policy and selecting the following:

  • Computer Configuration, Administrative Templates, System, Group Policy (to change the interval for computer policies and domain controllers)

  • User Configuration, Administrative Templates, System, Group Policy (to change the interval for user policies)

Changes made to existing GPOs or new GPOs being created are enforced when the refresh cycle runs. However, with the following settings, policies are enforced only at login or when booting a workstation to the domain, depending on the GPO configuration settings:

  • Software installation configured in the Computer Policies

  • Software installation configured in the User Policies

    Note

    When working with application settings, refresh intervals can be configured and customized to fit the environment needs. You should leave the refresh interval as the default, however, unless requirements call them to be modified.


Baseline Administration for Group Policy Deployment

Now that you have a base understanding of functionality and terminology of Group Policy, you can look at usage and how the configuration of Group Policy can vary greatly with each individual implementation.

Administrators can use this information to understand the more common methods of applying permissions to Group Policy for management purposes and the tools for testing Group Policy implementations prior to deployment in the production environment.

Note

In this section, some best practices for managing Group Policy are covered. For more information and details regarding Group Policy management, view the help information for managing Group Policy with Windows Server 2000 and Windows Server 2003.

Delegating Group Policy Management Rights

It is important to delegate the proper rights for administrators to manage and manipulate Group Policy. For example, in larger organizations, a very small group of users normally has permission to edit policies at the domain level. However, when specific requirements are needed to administer applications such as the Exchange client, permissions can be granted to specific areas with the Group Policy Management Console.

When creating specific permissions with the GPMC, administrators can delegate control for other administrators to manage the following areas within Group Policy:

  • Create GPOs

  • Create WMI filters

  • Permissions on WMI filters

  • Permissions to read and edit an individual GPO

  • Permissions on individual locations to which the GPO is linked, called the scope of management (SOM)

To easily assign permissions to GPOs, administrators can use the Delegation Wizard.

Working with Resultant Set of Policies

The new GPMC tool provides administrators with an additional function called Resultant Set of Policies (RSoP) for planning and testing Group Policy implementations prior to enforcing them on domain workstations and users. Using the RSoP tool in Planning mode, administrators can simulate the deployment of a specified group policy, evaluate the results of the test, make changes as needed, and then test the deployment again. After RSoP shows that the GPO is correct, the administrator can then back up the GPO configuration and import it into production.

To run RSoP in simulation mode, right-click on Group Policy Modeling in the forest that will be simulated, and choose Group Policy Modeling Wizard. The wizard enables you to input slow links, loop-back configuration, WMI filters, and other configuration choices. Each modeling is presenting in its own report as a subnode under the Group Policy Modeling node.

Tip

Because errors in Group Policy settings can affect users and client server connectivity, any Group Policy implementation should be tested using the RSoP tool in Planning mode before applying the policy.

Managing Group Policy Inheritance

To maximize the inheritance feature of Group Policy, keep the following in mind:

  • Isolate the servers in their own OU: Create descriptive Server OUs and place all the nondomain controller servers in those OUs under a common Server OU. If software pushes are applied through Group Policy on the domain level or on a level above the Server OU and do not have the Enforcement option checked, the Server OU can be configured with Block Policy Inheritance checked. As a result, the servers won't receive software pushes applied at levels above their OU.

  • Use Block Policy Inheritance and Enforcement sparingly to make troubleshooting Group Policy less complex.

Group Policy Backup, Restore, Copy, and Import

One new major improvement to Group Policy management offers the capability to back up (or export) the Group Policy data to a file. Using the backup functionality of the GPMC, any policy can be tested in a lab environment and then exported to a file for deployment in the production domain.

When backing up a group policy, you back up only data specific to that policy itself. Other Active Directory objects that can be linked to GPOs, such as individual WMI filters and TCP/IP security policies, are not backed up because of complications with restoration when working with these specific areas. When backup is completed, administrators can restore the Group Policy data in the same location, restoring proper functionality to misconfigured and accidentally deleted group policies.

The import functionality of the GPMC also enables administrators to take an exported Group Policy file and import the Group Policy data into a location other than its original one. This functionality is true even in scenarios in which no trust exists between domains.

Imports of Group Policy files can be completed using files from different domains, across forest domains, or within the same domain. This functionality is most powerful when you move a GPO from a test lab into production without having to manually re-create the policy setting tested in the lab environment.

Another helpful function of Group Policy Management is copying GPOs. If the administrator has configured a complex group policy and applied the setting to a specific organizational unit (OU) in the domain, the group policy can be copied and duplicated for application to another OU. When using the copy function, a new group policy is created when the copy function is performed. This new policy can then be placed and applied to the new location.


General Recommendations for Managing Clients Through Group Policy

There are some general rules of thumb to follow when using Group Policy to manage your network clients. This section details the best practices to keep in mind as you design your Group Policy solutions for most situations. It also provides some helpful tips on how to use software installations and folder redirection.

Keeping Group Policy Manageable

It has often been said that a simple solution is the best solution. Because Group Policy in Windows Server 2003 provides such a wide palette for customizing the network client experience, it can also become unwieldy as you build policy after policy in an effort to manage your environment. To avoid unnecessary complexity in your Group Policy solutions, keep the following recommendations in mind:

  • Use a common sense naming convention As you name the policies you build for your environment, stick to a naming convention that will help you easily identify the function of your policies. Windows Server 2003 does not prevent you from naming two policies with the same name, but it would be confusing if you did so. Also, keeping your policy names simple lends ease of designing and troubleshooting with the Resultant Set of Policy (RSoP) tools.

  • Use Block Policy Inheritance and No Override sparingly These features are great tools for applying Group Policy in organizations with strict hierarchical frameworks and for organizations with distributed administration. They can also make troubleshooting your policies difficult.

  • Disable unused parts of Group Policy Objects (GPOs) If your policy uses only User Configuration, you can disable Computer Configuration. Likewise, if you are modifying only Computer Configuration through policy, you can disable User Configuration. This will speed up the startup and logon process for those network clients receiving the policy.

  • Avoid cross-domain policy assignments Again, to expedite the startup and logon process, have your users receive their policy assignments from their own domain. The importance of this tip is particularly pertinent to the management of remote users.

Managing Client Software Installations

If your organization requires software installations that leverage scheduling, inventorying, reporting, or installation across a wide area network (WAN), you should add a Systems Management Server (SMS) solution to your management arsenal. If, on the other hand, you have simpler software installation and deployment scenarios, you can extend the use of Group Policy to fill this role. Keep in mind these points when deploying software to your network clients:

  • Assign or publish software to high-level Active Directory objects Because group policy settings apply by default to child containers, it is simpler to assign or publish applications by linking a Group Policy Object to a parent organizational unit or domain. Use security descriptors (ACEs) on the Group Policy Object for finer control over who receives the software.

  • Assign or publish just once per Group Policy Object For simpler management and troubleshooting, knowing that each installation package is associated with one group policy, and likewise each policy is associated with one piece of software, will alleviate future confusion. Also, do not assign or publish to both the Computer Configuration and User Configuration of a Group Policy Object.

  • Repackage existing software Because software is installed with Microsoft Windows Installer Packages (MSIs) via Group Policy, you may need to repackage software that is compiled with Setup.exe. Many third-party vendors supply utilities to develop installations in this native Windows format.

  • Specify application categories Using categories makes it easier for users to find an application in Add or Remove Programs in the Control Panel. You can define application categories, such as Engineering Applications, Marketing Applications, and so on.

Using Folder Redirection

You can use folder redirection to redirect certain special folders on the network client's desktop to network locations. Special folders are those folders, such as My Documents, that are located under Documents and Settings. Folder Redirection is a valuable extension of Group Policy that will come into play for some of the scenarios detailed later in this chapter. The following are some basic rules of thumb to guide you when using this Group Policy extension:

  • Allow the system to create the folders If you create the folders yourself, they will not have the correct permissions.

  • Do not redirect My Documents to the home directory This feature is available but should be used only if you have already deployed home directories in your organization. Redirection to the home directory is available only for backward compatibility.

  • Enable client-side caching This is important for users with portable computers.

  • Synchronize offline files before logging This feature of folder redirection should always be enabled to ensure that current files are available to users who work offline.

  • Use fully qualified (UNC) paths For example, use \\server\share. Although paths like c:\foldername can be used, the path may not exist on all your target network clients, and redirection would fail.


Using Group Policy for System Updates and Patch Management

With security patches and updates coming on a regular basis, one of the major advantages to Group Policy is the centralized deployment options available to distribute the updates and patches. With Group Policy and the Microsoft MSI installation package format available with most updates, software updates can be deployed from the centralized administrative distribution point to a predefined set of workstations configured in the GPO settings.

Deployment Options When Updating Network Clients

Using Group Policy, network client systems can be upgraded and patched using one of the three following deployment methods:

  • Assigned to Computers This method of installation adds the software package to the workstation and is available when the workstation is restarted. Using this option, systems can be updated on a regular basis.

  • Assigned to Users When the installation package is assigned to users, Application Shortcuts are placed on the desktop of the user's profile and on the Start menu. When these shortcuts are selected, the application installation will be initiated.

    Tip

    When using the Assigned Application options for both users and computers only, when a package is uninstalled, Group Policy automatically reassigns the installation to the user or computer.

  • Publishing the Installation This is the most common method of deploying software updates to client systems. When a software package is published, the installation package is displayed in the Add/Remove Programs Group in the local desktop system control panel. Users can then initiate the installation by selecting the update.

Each method enables network administrators to push MSI software update packages to the network workstation from a central location or Administrative Installation Point, to the workstation or users on the network.

Caution

Do not assign the option to install updates to Users and Computers at the same time. Assigning both options can create conflict to how updates are installed, and possibly corrupt the installation of the application or update when it is applied.

Deploying Client Updates

As with all aspects of Group Policy, the choices and configuration options of deployment updates are numerous. Regardless of which type of update package is being pushed, some basic best practices apply and can help make updates easier and less troublesome:

  • Software packages must be in the format of an MSI package. Any other format type cannot be pushed using Group Policy. Third-party applications can help the administrator create customized MSI packages to deploy any type of software, as well as software with predefined installation choices.

  • Configure software pushes at the highest levels possible in the domain. If the push is going out to more than one group or organizational unit, the software update should be configured to be pushed at the domain level. If the software update is being pushed to only a few groups or one organizational unit, or if multiple update packages are being pushed, configure the push at the group or organizational unit level.

  • Configure software pushes to the Computers configuration rather than the User configuration. This way, if users log in to multiple computer systems, updates are not applied more than once.

  • When pushing updates in multiple locations, use a technology such as Distributed File System (DFS) so software installations are installed from packages and sources close to the client being updated.

Pushing Client Updates

With the options available and a good understanding of the best practices for deploying software, the next step is to configure a Group Policy Object to push an update to the network workstation. The steps in this scenario enable administrators to push a small update package to workstations in the domain.

Begin by downloading the update and creating a share on the folder where the update will be placed. Open the GPMC by selecting Start, All Programs, Administrative Tools, Group Policy Management. To create a software update Group Policy Object, follow these steps:

1. | Select the Default Domain Policy for your domain by selecting Forest, Domains, YourCompanydomain, Group Policy Objects.
2. | Select Default Domain Policy, Action, Edit. This opens the Group Policy Editor to create the software push.
3. | Select Computer Configuration and then select Software Settings, Software Installation.
4. | From the Action menu, select New, Package.
5. | Navigate the Open dialog to the network share where the MSI was placed and select the MSI package being applied. Select Open to continue. Tip If prompted that the Group Policy Editor cannot verify the network location, ensure that the share created earlier in these steps has permission allowing users access to the share. Select Yes to continue after confirmation.
6. | At the Deploy Software dialog box, select Advance and click OK to continue. Windows will verify the installation package; wait for the verification to complete before continuing to the next step.
7. | When the Package is visible in the right window of the software installation properties, highlight the install package and click Action, Properties.
8. | On the Package properties page, select the Deployment tab. Review the configuration, click Assign, and ensure that the Install This Package At Logon option is selected. Select OK when this is complete.

The new package is ready to deploy. Test the update by logging on to a workstation and verifying that the package has installed. If problems exist, redeploy the package by selecting the software update and clicking Action, All Tasks, Redeploy Application to force the deployment.

Determining the Success of a Push

Without additional management software, administrators cannot determine whether a software package was pushed successfully, because all evidence of software pushes are seen locally on the client machines. On the local machines, there are two areas to check to determine whether a software installation was successful:

  • Look for MSI Installer events that are written into the Application Event Logs.

  • On the local machine, view Add/Remove programs to see whether the Outlook update package is listed.


Real-Life Scenarios of Group Policy Management

Now that you have some working recommendations for managing network clients with Group Policy, the remainder of this chapter guides you in a detailed fashion on Group Policy strategies for specific network client scenarios. Every organization has groups and individuals who have unique requirements of the company's network resources. Users who dial in to the network have different needs than office workers who always work from their desks. A network administrator requires a different workstation environment than an employee with a limited set of applications. Technologies in the Windows Server 2003 framework, including Group Policy, enable you to accommodate these different needs. When you can identify the particular types of network clients that you support, you can begin to develop particular strategies and Group Policy solutions for managing those clients. The following sections address some of the most common types of network clients and provide recommendations for managing their unique scenarios.

Working with Mobile Users

Many companies have employees who either frequently travel or are located away from the typical office environment. These mobile users are unique because they usually log on to the company network through a portable computer from different locations over a slow-link dial-up modem connection. Although mobile users differ, both the slow-link connection and lack of local access should be used as the defining qualities for this type of network client. As such, your Windows Server 2003 and Group Policy strategy for managing this type of user should take into account the slow link and lack of local access.

Because mobile users are away from the local office, they are in the unique situation of often having to provide for their own computer support. As such, you may want to grant your mobile users more privileges than standard office users. To do this, you apply a Group Policy Object to your mobile clients that would allow the users to perform functions such as printer or software installs, while at the same time protect critical system files.

Mobile users also expect access to their critical data whether or not their portable computers are connected to the network. The Offline Files feature of IntelliMirror simplifies management of mobile users in that it allows the users to work on network files when they are not actually connected to the network. Even though Offline files are enabled in Windows 2000 and XP by default, you still need to select the network files and folders for synchronization before giving portable computers to the users.

To set up a folder for offline access, perform the following steps:

1. | Click the shared network folder that you want to make available offline.
2. | Select File, Make Available Offline.
3. | The Offline Files Wizard will open; click Next to continue.
4. | Choose whether or not to synchronize automatically during logon and logoff and click Next.
5. | Choose to have reminders pop up stating whether you are working online or offline and click Finish. This wizard will only appear for the first folder configured to work offline.

Note

For offline folders to work, the offline folder function needs to be enabled. To enable it, within Windows Explorer, select Tools, Folder Options. Next, click the Offline Files tab, select Enable Offline Files, and then click OK.

Combining folder redirection with offline file access makes sense for mobile users. If you redirect the My Documents folder to a network share, when users save files to My Documents, they will be automatically made available for offline use.

Note

Mobile users are likely to disconnect from their dial-up session to the network without properly logging off. It is recommended that you set offline files to synchronize when users log on and periodically synchronize in the background. This way, you can ensure that the users' files are always up to date.

To redirect the My Documents folder to a network share, perform the following steps:

1. | Open a Group Policy Object that is linked to the organizational unit that contains the mobile users.
2. | In the console tree under user Configuration/Windows Settings, double-click Folder Redirection to display the special folder that you want to redirect.
3. | Right-click the folder that you want to redirect (in this case, My Documents) and then click Properties.
4. | On the Target tab, click Basic - Redirect Everyone's Folder to the Same Location in the Setting area.
5. | Under Target Folder Location, click Redirect to the Following Location. In Root Path, type a UNC path (for example, \\server\share). Folder redirection automatically appends the username and folder name when the policy is applied.

Software installation for mobile users requires a unique strategy. It is not recommended to assign or publish software for mobile users who are rarely in the office. If they periodically work in the office, you can set the Group Policy slow-link detection to the default in the user interface so that software will install only when the user is connected directly to the local area network (LAN).

You can verify or adjust the connection speed for Group Policy settings in the Group Policy slow-link detection setting. To do this in the Group Policy Object Editor, navigate to Computer Configuration/Administrative Templates/System/Group Policy or User Configuration/Administrative Templates/System/Group Policy.

Mobile users should not, for the most part, be running networkbased applications. Typically, your mobile users' portable computers should have all the core software installed before they have to work outside the office. If users require additional software after they are in the field and cannot return to the office to have it installed, it may make sense to copy your software packages to CD to be installed locally by the mobile users with elevated privileges.

Managing Remote Users

Remote users share many of the characteristics of the mobile users discussed in the preceding section. As such, they also benefit from many of the same technological recommendations made for managing mobile users. This includes offline file access combined with folder redirection. Remote users as a network client type may be distinguished from mobile users in that they typically connect to a network from a static location (although remote from the office), and they often benefit from a higher-speed connection such as DSL or cable modem. Whereas a traveling mobile user logs in to your network from hotel rooms and airport kiosks over a dial-up modem, the remote user often works from home and connects over a high-speed DSL or cable modem.

With the added benefit of a high-speed connection, software installations that are published or assigned through Group Policy can be implemented to remote users. This, in turn, allows you to lock down some of the privileges you may have granted to your mobile users through Group Policy (such as software installation). Preventing your remote users from installing their own software or making configuration changes to their computers reduces total cost of ownership.

If you intend to implement additional security to your remote users' connections to the network, you should implement a virtual private network (VPN) server solution. A VPN is a Windows Server 2003 Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP) technology deployment that creates a secure remote access network connection. Although implementing a VPN solution is outside the context of this chapter, some policy-related items should be considered.

You should create an Active Directory group (such as VPN_Users) for those remote users who will be connecting to the network over the VPN connection. You will use this group name in the conditions section of the Remote Access Policy. In the dial-in properties of each user account, you should set Control Access through Remote Access Policy.

Next, create the Group Policy Object for the Remote Access policy that will define the authentication and encryption settings for the remote users. Assuming you already have a Windows Server 2003 server configured for VPN using Routing and Remote Access, you can configure additional remote access policies through Routing and Remote Access as follows:

1.
In Routing and Remote Access, right-click Remote Access Policies, located under the Server object and choose New Remote Access Policy.

2.
The New Remote Access Policy Wizard opens; click Next on the welcome page to continue.

3.
Choose Use the Wizard to Set Up a Typical Policy for a common scenario and enter VPN authentication for the policy name. Press Next to continue.

4.
Select VPN on the Access Method property page.

5.
Grant access to the group you created for the VPN users in the User or Group Access property page.

6.
For Authentication Methods, select the appropriate authentication method that your current infrastructure supports and click Next.

7.
On the Policy Encryption Level property page, select Strong and Strongest.

8.
Click on the Policy Encryption Level page and click Finish to create the policy.

9.
Once the policy is created, double-click the policy in the right pane and, under the policy conditions section, add the Called-Station-ID and enter the Internet-based IP address of your VPN server. Your policy should look similar to Figure 29.1.

Figure 29.1. Policy settings for routing and remote access.

Locking Down Workstations

In some companies, employees have total control of their desktop computers regardless of their business function or computer expertise. When these users have problems, they call you or your IT department. This scenario proves to be very expensive to support. These support costs are decreased the more you adopt and enforce network client standards and limit the ability of users to change the standard configurations. The degree to which you choose to limit your users' control over their desktop environment depends on the roles these users play in the company and their level of computer expertise.

You should limit some groups more than others. For example, a data entry clerk who uses a computer solely to input data into a database requires little or no control over the desktop configuration, whereas a software programmer possessing a high level of computer expertise requires more control of the desktop environment. You can create different organizational units (OUs) and apply different group policies based on the level of desktop control you allow these groups of network clients.

This section reviews Group Policy configuration recommendations for a highly managed network client. A good example of a highly managed network client would be a data entry clerk. Data entry clerks use computers to enter data that will then be available for other corporate functions. Data entry workers are dedicated to a single task and normally use a single line-of-business application (or a small number of related applications) to do their jobs. System services such as virus checkers are the only other applications installed. Bank tellers, data entry personnel, factory line workers, and transcriptionists fall into this category. These users require a standard application with no specialized or customized configurations.

To manage the data entry clerk, you should implement a highly managed configuration that does not require the user to have computer skills for data management, software installs, or system configuration. Characteristics of the policies associated with the highly managed network client include the following:

  • Desktops have a limited set of applications that the user can run. You can limit, through Group Policy, which applications the user can execute. To do this in the Group Policy Editor, navigate to User Configuration/Administrative Templates and expand Start Menu and Taskbar.

    Note

    You can launch the Group Policy Editor by right-clicking the OU and selecting the Group Policy Object tab.

  • Desktops have no Start menu and may have limited desktop icons. You need to hide Network Neighborhood and other icons that normally appear on the desktop. You can see in Figure 29.2 the many options you have for limiting the Start menu and taskbar.

  • Users cannot install software. The software the users require is already installed on their computers.

  • All data is stored on the network. You can implement folder redirection to satisfy this requirement. To set up folder redirection for a folder on your highly managed client, follow these steps:

    1.
    Open a Group Policy Object that is linked to the organizational unit for these clients.

    2.
    In the console tree under User Configuration/Windows Settings, double-click Folder Redirection to display the special folder that you want to redirect.

    3.
    Right-click the folder that you want to redirect (in this case, My Documents) and then click Properties.

    4.
    On the Target tab, click Basic - Redirect Everyone's Folder to the Same Location in the Setting area.

    5.
    Under Target Folder Location, click Redirect to the Following Location. In Root Path, type a UNC path (for example, \\server\share). Folder redirection automatically appends the username and folder name when the policy is applied.

  • If the highly managed users all save data to the same server volume, you can then also implement disk quotas on the network shares for them. To enable disk quotas that limit users to a particular amount of hard disk space, follow these steps:

    1.
    On your server, right-click the appropriate disk volume and click Properties.

    2.
    In the Properties dialog box, click the Quota tab.

    3.
    On the Quota tab, check the Enable Quota Management box.

    4.
    Select Limit Space To and then specify the amount of disk space.

  • You can also enforce disk quota limits through Group Policy. To do this in the Group Policy Editor, navigate to Computer Configuration/Administrative Templates/System/Disk Quotas.

  • Many users, working on different shifts or on temporary contracts, can share computers. You should set up roaming profiles so that the users' desktop settings follow them regardless of the workstation in use. To create a roaming user profile, do the following:

    1.
    In Active Directory Users and Computers, right-click the applicable user account and choose Properties.

    2.
    In the Properties dialog box, click the Profile tab.

    3.
    In the Profile Path, type a path to a server share for the profile specifying the username, such as \\servername\share\%username%.

Figure 29.2. Options for limiting the Start menu and taskbar.

[View full size image]

Supporting Power Users

As you can see from the preceding section, you can really lock down a network client's ability to change the desktop standards you set in place. Of course, for many of your network clients, to have a workstation that's too restrictive would hamper productivity and cause great frustration. There are always groups in every organization that require more control of the workstation. To meet this need, you should not have to provide complete control of your carefully designed desktop standards. You can still maintain a level of control over your network clients while at the same time provide a productive desktop environment to your more demanding users.

This section focuses on these more demanding users, who can be characterized as lightly managed network clients. A good example of a lightly managed network client is a software developer. Software developers' job success is completely dependent on their use of technology. They require highly specialized software applications to carry out their jobs and make relatively little use of office productivity applications. These workers can be either project-driven or process-driven. Because their salaries are high and their job value is directly tied to their use of technology, computer downtime for these individuals is extremely costly. Financial traders and other types of engineers also fall into this category.

To manage your software developer network client, you should implement a lightly managed desktop policy. You can maximize the user's ability to perform the job function by removing obstacles and distractions, while at the same time maintaining a level of manageability to reduce total cost of ownership. Characteristics of the policies associated with the lightly managed desktop include the following:

  • Users run with Power Users privileges. To give your software developers more control over their workstation than standard users, add the users' accounts to the local Power Users group on the workstation.

  • You can also implement roaming profiles if these users will be using more than one workstation. This way, the users' desktop settings will be consistent across the various machines they use. To create a roaming user profile, perform the following steps:

    1.
    In Active Directory Users and Computers, right-click the applicable user account and choose Properties.

    2.
    In the Properties dialog box, click the Profile tab.

    3.
    In the Profile Path, type a path to a server share for the profile specifying the username, such as \\servername\share\%username%.

  • Users can configure installed applications to suit their needs. Being a member of the Power Users group enables this functionality, provided you have not applied a group policy that limits the system directories on the workstation.

  • Users cannot change standard hardware settings. Unless the users are directly working with hardware that will interface with the workstation, you should maintain control of your hardware configurations. To secure many of your hardware settings through Group Policy, navigate to Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignments. Drivers for a selected group of plug-and-play drivers can be preinstalled to allow the users to connect and disconnect devices (such as scanners or local printers).

  • Users cannot remove critical applications, such as antivirus software. If you repackage your antivirus software installation to create an MSI, you can specify in the package not to show this software in the Add or Remove Programs Control Panel applet. You can also prevent the files from being deleted on the workstation by setting security on those files so that they can be deleted only by an administrator.

  • Although critical data is stored on the network, users have the ability to store data locally. You should implement folder redirection and offline file access. To set up folder redirection, follow these steps:

    1.
    Open a Group Policy Object that is linked to the organizational unit for these clients.

    2.
    In the console tree under User Configuration/Windows Settings, double-click Folder Redirection to display the special folder that you want to redirect.

    3.
    Right-click the folder that you want to redirect and then click Properties.

    4.
    On the Target tab, click Basic - Redirect Everyone's Folder to the Same Location in the Setting area.

    5.
    Under Target Folder Location, click Redirect to the Following Location. In Root Path, type a UNC path (for example, \\server\share). Folder redirection automatically appends the username and folder name when the policy is applied.

Providing a High Level of Security

In the preceding scenarios, you were presented with recommendations on how to provide or limit particular functionality to the network client based on the role that client played in the organization. In this section, the focus is on how to increase the security of the network client. Most organizations have groups or individual network clients who work with or require access to highly confidential data. You may have such users working in the Human Resources or Payroll departments of your company. Executives in the company also fall under this category. Because these users are privileged to very sensitive information, it is important for you to secure the network accounts used to access this information as well as the means by which this data is accessed.

Though Windows Server 2003 security is addressed in Part IV, "Security," in this book, this section outlines some security recommendations as they relate to managing high-security network clients through Group Policy.

Because you probably store sensitive data on servers that is, in turn, accessed by privileged network clients, you should secure that data as it passes from server to client. Most data is not protected when it travels across the network, so employees, supporting staff members, or visitors may be able to plug in to your network and copy data for later analysis. They can also mount network-level attacks against other computers. Internet Protocol Security (IPSec), a built-in feature of Windows Server 2003, is a key component in securing data as it travels between two computers. IPSec is a powerful defense against internal, private network, and external attacks because it encrypts data packets as they travel on the wire.

You can create and modify IPSec policies using the IP Security Policy Management snap-in available in the Microsoft Management Console. IPSec policies can then be assigned to the Group Policy Object of a site, domain, or organizational unit. If your sensitive data is located on a server, you should assign the predefined Secure Server policy to the server so that it always requires secure communication. You can then assign the predefined Client (Respond Only) policy to the network clients that will communicate with the secure server. This policy ensures that when the network client is communicating with the secure server, the communication is always encrypted. The network client can communicate normally (unsecured) with other network servers.

To assign the Client (Respond Only) IPSec policy in the Group Policy Object Editor, perform the following steps:

1. | Navigate to IP Security Policies on Active Directory under Computer Configuration/Windows Settings/Security Settings.
2. | In the details pane, click Client (Respond Only).
3. | Select Action, Assign.

Although it may be okay for your high-security network client to communicate normally (unsecured) with other servers within your organization that do not contain sensitive data, you may still want to limit that client's ability to communicate outside the organization. You can enable several settings within Group Policy to prevent a user from modifying or creating new network connections. For example, a Group Policy setting can be applied to prohibit connecting a remote access connection.

To enable Group Policy settings related to network connections in the Group Policy Editor, navigate to User Configuration/Administrative Templates/Network. Figure 29.3 displays the settings you can enable in this category.

Figure 29.3. Settings for network connections.

[View full size image]

If your secure network clients save sensitive data to their local workstations, you can provide additional security to this data through the Encrypting File System (EFS). Because EFS is integrated with the file system, it is easy to manage and difficult to attack. Moreover, once a user has specified that a file be encrypted, the actual process of data encryption and decryption is completely transparent to the user. How data encryption and decryption works is explained in detail in Chapter 12, "Server-Level Security."

To encrypt a file or folder, follow these steps:

1. | In Windows Explorer, right-click the file or folder that you want to encrypt and then click Properties.
2. | On the General tab, click Advanced.
3. | Check the Encrypt Contents to Secure Data box.

To encrypt and decrypt files, a user must have a file encryption certificate. If the file encryption certificate is lost or damaged, access to the files is lost. Data recovery is possible through the use of a recovery agent. A user account of a trusted individual can be designated as a recovery agent so that a business can retrieve files in the event of a lost or damaged file encryption certificate or to recover data from an employee who has left the company.

One of the many advantages of using Windows Server 2003 domains is that you can configure a domain EFS recovery policy. In a default Windows Server 2003 installation, when the first domain controller (DC) is set up, the domain administrator is the specified recovery agent for the domain. The domain administrator can log on to the first DC in the domain and then change the recovery policy for the domain.

If you want to create additional recovery agents, the user accounts must have a file recovery certificate. If available, a certificate can be requested from an enterprise Certificate Authority (CA) that can provide certificates for your domain. However, EFS does not require a CA to issue certificates, and EFS can generate its own certificates to users and to default recovery agent accounts.

Maintaining Administrator Workstations

At this point, you have established and applied Group Policy to all your network clients based on their function, location, and security needs to provide a productive and manageable desktop or laptop experience. You must now turn your attention to the network clients that manage the network: the administrators' workstations. In many companies, the administrators' workstations have no controls in place at all. The accounts the administrators use to log on to the network give them access to control every aspect of the workstation, as well as the servers. Because these accounts have so much power over the network, it is recommended that policies are in place to protect that power (see Figure 29.4). This section suggests some recommendations in the proper configuration and use of the administrator workstation.

Figure 29.4. Public key policy options and settings.

[View full size image]

To make changes in Active Directory, perform system maintenance, run backups and restores, and install software, administrators require a logon account that gives them elevated privileges. At the same time, administrators also perform normal network activity such as reading email, writing documents, and setting schedules. For this reason, administrators should have two or more accounts. They should have an account that behaves as a normal network client account with the same privileges and subject to the same Group Policy as most normal users or power users. This account would then be used as the standard logon for the administrator workstation. They should then have other accounts for workstation administration and network or domain administration that remain secure in virtue of not being used during the day-to-day network client work. Even administrators can inadvertently make damaging changes to a workstation or server configuration if they are logged in with Domain Admin privileges all the time.

The Run As feature of Windows Server 2003 and Windows 2000 can be used from an administrator workstation or any network client to elevate privileges temporarily to perform administrative functions. For example, while logged in to a workstation with a user account that has standard user privileges, you can run Active Directory Users and Computers using the Run As command to execute the utility from an administrative account.

To run an application with the Run As command, do the following:

1. | While holding down the Shift key on the keyboard, right-click the application you want to run.
2. | Click Run As.
3. | In the Run As Other User dialog box, type the username, password, and domain name of the administrative account.

It is also recommended to enforce a password-protected screensaver with a short timeout interval on administrator workstations. This protects the workstation from malicious users taking advantage of the administrator's credentials should the administrator be temporarily away from the machine.

To specify a particular screensaver with password protection and timeout in a Group Policy, do the following:

1.
In the Group Policy Object Editor, navigate to User Configuration/Administrative Templates/Control Panel/Display.

2.
Enable the following settings: Screen Saver Executable Name, Password Protect the Screen Saver, and Screen Saver Timeout. Figure 29.5 shows these settings enabled.

Figure 29.5. Control Panel display setting policies.

[View full size image]

Note

Group Policy administrators should keep in mind that user accounts belonging to the Domain Admins or Enterprise Admins groups do not have group policy applied to their accounts by default and should be enabled with extreme caution.

Finally, when you're dealing with a large organization with distributed administration, it is a good idea to delegate authority for your network clients to administrator groups based on geographical location. Some organizations make the mistake of creating a global administrators group populated with every administrator in the company. Just because an administrator in the Santa Clara office requires administrative rights over the network clients in his office does not mean that he should also get administrative rights over network clients in Papua, New Guinea. Keeping your administrators organized also protects your network clients from receiving improper Group Policy assignments.


Summary

You can see that Group Policy in Windows Server 2003 can address network client management needs for a wide array of scenarios. You can fine-tune your management policies based on the function, location, and security needs of your users. From the scenarios examined in this chapter, you can construct management policies specific to your own organization. Although this chapter offers some solid recommendations for typical organizational groups, you may find unique management requirements in your own management design. As you begin to explore the multitude of Group Policy settings available in Windows Server 2003, keep in mind that the simplest solutions are often the best from both a management perspective and a productive end user perspective.


Best Practices

  • Stick to a naming convention that will help you easily identify the function of your policies as you name the policies you build for your environment. Windows Server 2003 does not prevent you from naming two policies with the same name, but it would be confusing if you did so.

  • Use Block Policy Inheritance and No Override sparingly. These features are great tools for applying Group Policy in organizations with strict hierarchical frameworks and for organizations with distributed administration. They can also make troubleshooting your policies difficult.

  • Disable unused parts of Group Policy Objects. If your policy uses only User Configuration, you can disable Computer Configuration. Likewise, if you are modifying only Computer Configuration through policy, you can disable User Configuration. This speeds up the startup and logon process for those network clients receiving the policy.

  • Avoid cross-domain policy assignments. Again, to expedite the startup and logon process, have your users receive their policy assignments from their own domains. The importance of this tip is particularly pertinent to the management of remote users.

  • Assign or publish software to high-level Active Directory objects. Because Group Policy settings apply by default to child containers, it is simpler to assign or publish applications by linking a Group Policy Object to a parent organizational unit or domain.

  • Assign or publish just once per Group Policy Object. Again, for simpler management and troubleshooting, knowing that each installation package is associated with one group policy and likewise each policy is associated with one piece of software will alleviate future confusion. Also, do not assign or publish to both the Computer Configuration and User Configuration of a Group Policy Object.

  • Repackage existing software. Because software is installed with Microsoft Windows Installer Packages (MSIs) via Group Policy, you may need to repackage software that is compiled with Setup.exe.

  • Allow the system to create the folders. If you create the folders yourself, they will not have the correct permissions.

  • Do not redirect My Documents to the home directory. This feature is available but should be used only if you have already deployed home directories in your organization. Redirection to the home directory is available only for backward compatibility.

  • Enable client-side caching. This is important for users with portable computers.

  • Synchronize offline files before logging. This feature of folder redirection should always be enabled to ensure that current files are available to users who work offline.

  • Use fully qualified (UNC) paths, such as \\server\share. Although paths like c:\foldername can be used, the path may not exist on all your target network clients, and redirection would fail.

  • Use the Offline Files feature of IntelliMirror to simplify management of mobile users. This feature allows the users to work on network files when they are not actually connected to the network.

  • Set offline files to synchronize when users log on and periodically synchronize in the background. This way, you can ensure that the users' files are always up to date.

  • Implement a virtual private network (VPN) server solution if you intend to implement additional security to your remote users' connections to the network.

  • Implement a highly managed configuration that does not require highly managed users to have computer skills for data management, software installs, or system configuration. If the highly managed users all save data to the same server volume, you can then also implement disk quotas on the network shares for them.

  • Implement a lightly managed desktop policy to manage your software developer network clients. These users should run with Power Users privileges. Being a member of the Power Users group enables this functionality, provided you have not applied a group policy that limits the system directories on the workstation.

  • Implement IPSec group policies and use Encrypting File System for high-security users.

  • Have administrators use standard user accounts to do their day-to-day tasks and use administrator accounts only when the task demands it. Enforce screensavers on Administrator workstations.


Part IX: Fault Tolerance Technologies

In This Part

CHAPTER 30 File System Fault Tolerance

CHAPTER 31 System-Level Fault Tolerance (Clustering/Network Load Balancing)

CHAPTER 32 Backing Up a Windows Server 2003 Environment

CHAPTER 33 Recovering from a Disaster


Chapter 30. File System Fault Tolerance

In This Chapter

  • Examining Windows Server 2003 File System Services

  • Using Fault-Tolerant Disk Arrays

  • Managing File Share Access and Volume Usage

  • Leveraging the Capabilities of File Server Resource Manager

  • Monitoring Disks and Volumes

  • Working with Operating System Files: Fault Tolerance

  • Using the Distributed File System Replication

  • Planning a DFS Deployment

  • Installing DFS

  • Optimizing DFS

  • Managing and Troubleshooting DFS

  • Backing Up DFS

  • Handling Remote Storage

  • Using the Volume Shadow Copy Service

Modern businesses rely heavily on their computing infrastructure, especially when it comes to accessing data. Users access databases and files on a regular basis, and when the necessary data is unavailable, productivity can suffer and money can be lost. Also, when new file servers are added to the environment to replace old file servers or just to accommodate additional load, administrators must change user login scripts and mapped drive designations but may also need to manually copy large amounts of data from one server to another. Keeping heavily used file servers optimized by regularly checking disks for errors or file fragmentation and archiving data to create additional free disk space can take considerable time. In most cases, such tasks require taking the server offline, leaving the data inaccessible.

In this chapter, we highlight the technologies built into Windows Server 2003 that help improve reliable file system access. This chapter also covers best practices on ways to implement these technologies as well as ways to maintain and support the file system services to keep information access reliable and recoverable.


Examining Windows Server 2003 File System Services

There are many ways to create fault tolerance for a file system using services and file system features included in the Windows Server 2003 family of operating systems. Depending on whether security, automated data archival, simplified file server namespaces, data replication, or faster data recovery is the goal, Windows Server 2003 provides file system features and services that can enhance any computing environment.

Distributed File System

In an effort to create highly available file services that reduce user configuration changes and file system downtime, Windows Server 2003 includes the Distributed File System (DFS) service. DFS provides access to file data from a unified namespace that redirects users from a single network name to shared data hosted across various servers. For example, \\companyabc.com\home could redirect users to \\server3\home$ and \\server2\users. Users benefit from DFS because they need to remember only a single server or domain name to locate all the necessary file shares. When deployed in a domain configuration, DFS can be configured to replicate data between servers using the File Replication Service.

Distributed File System Replication

With the release of Windows 2003 R2, Microsoft updated DFS to a new revision called Distributed File System Replication, or DFSR. DFSR uses the core technology from which DFS was built, and adds more functionality for better replication processes, algorithms, and capabilities. DFSR commonly is simply called DFS because most organizations that have been using DFS since Windows 2000 and the original release of Windows 2003 have been calling the service DFS. In terms of this book, the reference to DFS and DFSR is interchangeable, with updated references to DFSR being noted throughout this chapter.

File Replication Service

The File Replication Service (FRS) is automatically enabled on all Windows 2000 and Windows Server 2003 systems but is configured to automatically start only on domain controllers. On Windows 2000 and Windows Server 2003 domain controllers, FRS is used to automatically replicate the data contained in the SYSVOL file share, including system policies, Group Policies, login scripts, login applications, and other files that administrators place in the SYSVOL or the Netlogon shares. When a domain controller is added to a domain, FRS creates a connection or multiple connections between this server and other domain controllers. This connection manages replication using a defined schedule. The default schedule for domain controller SYSVOL replication is always on. In other words, when a file is added to a SYSVOL share on a single domain controller, replication is triggered immediately with the other domain controllers it has a connection with. When domain controllers are in separate Active Directory sites, the FRS connection for the SYSVOL share follows the same schedule as Active Directory. The SYSVOL FRS connection schedule is the same as the site link. Domain-based DFS hierarchies can also use FRS connections to replicate file share data for user-defined shares.

Although FRS and domain DFS provide multi-master automated data replication, the Volume Shadow Copy service can be used to manage the actual content or data contained within the shares.

Volume Shadow Copy Service

The Volume Shadow Copy service (VSS) is new to Windows Server 2003 and provides file recoverability and data fault tolerance never previously included with Windows. VSS can enable administrators and end users alike to recover data deleted from a network share without having to restore from backup. In previous versions of Windows, if a user mistakenly deleted data in a network shared folder, it was immediately deleted from the server and the data had to be restored from backup. A Windows Server 2003 volume that has VSS enabled allows a user with the correct permissions to restore that data from a previously stored VSS backup. Using VSS on a volume containing a shared folder, the administrator can simply restore an entire volume or share to a previous state, or just restore a single file.

Remote Storage

To provide hierarchical storage management services, including automated data archiving, Windows Server 2003 includes the Remote Storage service first introduced in Windows 2000 Server. This service can be configured to migrate data from a disk volume to remote storage media based on last file access date, or when a managed disk reaches a predetermined free disk space threshold, data can be migrated to remote media automatically. Although this service does not provide file system fault tolerance, using Remote Storage to manage a volume can improve reliability and recoverability by keeping disk space available and by reducing the amount of data that needs to be backed up or restored when a disk failure occurs.

Note

Do not configure Remote Storage to manage volumes that contain FRS replicas because doing so can cause unnecessary data migration. Periodically, FRS may need to access an entire volume to send a complete volume copy to a new server replica, and this can create several requests to migrate data back to a disk from remote storage media. This process can be lengthy because all the managed volumes' migrated data may need to be restored to the server's physical disk.


Using Fault-Tolerant Disk Arrays

Windows Server 2003 supports both hardware- and software-based RAID volumes to create fault tolerance for disk failures. Redundant Array of Inexpensive Disks (RAID) provides different levels of configuration that deliver disk fault tolerance, and formatting such volumes using the NT File System (NTFS) also allows directory- and file-based security, data compression, and data encryption to be enabled. Hardware-based RAID is preferred because the disk management tasks are offloaded to the RAID controller, reducing the load on the operating system. When a disk is available to Windows Server 2003, it can be configured as a basic disk or a dynamic disk.

Disk Types

Windows Server 2003 can access disks connected directly to the server from an IDE controller, SCSI controller, or an external RAID controller. RAID disks can provide faster disk access times but also can provide fault tolerance for disk failures.

Hardware-based RAID is achieved when a separate RAID disk controller is used to configure and manage the RAID array. The RAID controller stores the information on the array configuration, including disk membership and status. Hardware-based RAID is preferred over Windows Server 2003 software-based RAID because the disk management processing is offloaded to the RAID card, reducing processor utilization.

As mentioned previously, Windows Server 2003 supports two types of disks: basic and dynamic. Basic disks are backward compatible, meaning that basic partitions can be accessed by previous Microsoft operating systems such as MS-DOS and Windows 95 when formatted using FAT; and when formatted using NTFS, Windows NT, Windows 2000, and Windows Server 2003 can access them. Dynamic disks are managed by the operating system and provide several configuration options, including software-based RAID sets and the ability to extend volumes across multiple disks.

Basic Disks

Basic disks can be accessed by Microsoft Windows Server 2003 and all previous Microsoft Windows or MS-DOS operating systems. These disks can be segmented into as many as four partitions. The combination of partitions can include up to four primary partitions or three primary partitions and one extended partition. Primary partitions can be used to start legacy operating systems and are treated as a single volume. An extended partition can be broken into multiple logical drives. Each logical drive is managed as a separate volume, allowing administrators to create as many volumes on a basic disk as necessary. Basic partitions and logical drives can be formatted as either FAT, FAT32, or NTFS disks. Basic partitions are also referred to as basic volumes.

Dynamic Disks

Dynamic disks can be segmented into several logical drives referred to as dynamic volumes. Dynamic disks are managed by the operating system using the Virtual Disk Service (VDS). Many volumes can be defined on a dynamic disk, but limiting the number of volumes to 32 or fewer is recommended. After a disk is converted to a dynamic disk, it can be mounted only by Windows Server 2003 systems, but the data can still be accessed by other operating systems using Windows Server 2003 file services, including Web services, FTP services, file shares, and other client/server-based applications.

In some configurations, dynamic volumes can span two or more disks and provide disk fault tolerance. Dynamic volume types provided in Windows Server 2003 include the following:

  • Simple volume A simple volume is similar to a basic partition in that the entire volume is treated as a single drive and it does not span multiple disks.

  • Spanned volume A spanned volume is treated as a single drive, but the volume spans two or more disks. Spanned volumes provide no disk fault tolerance but can be used to meet disk storage needs that exceed the capacity of a single disk. Spanned volumes are slowest when it comes to reading and writing data and are recommended only when the space of more than a single disk is necessary or an existing simple partition needs to be extended to add disk space. For instance, if an application does not support the moving of data or system files to another drive and the current drive is nearly full, a simple volume can be extended with unallocated space on the same or another disk to add additional disk space. A simple volume that has been extended with unallocated space on the same disk is still considered a simple volume. The allocated space on each of the disks can be of different sizes.

  • Striped volume A striped volume or RAID 0compatible volume requires two or more disks and provides the fastest of all disk configurations. Striped volumes read and write data from each of the disks simultaneously, which improves disk access time. Striped volumes utilize all the space allocated for data storage but provide no disk fault tolerance. If one of the disks should fail, the data would be inaccessible. Stripe sets require the exact amount of disk space on each of the allocated disks. For example, to create a 4GB stripe set array with two disks, 2GB of unallocated space would be required on each disk.

  • RAID 5 volume Software-based RAID 5 volumes require three or more disks and provide faster read/write disk access than a single disk. The space or volume provided on each disk of the RAID set must be equal. RAID 5 sets can withstand a single disk failure and can continue to provide access to data using only the remaining disks. This capability is achieved by reserving a small portion of each disk's allocated space to store data parity information that can be used to rebuild a failed disk or to continue to provide data access. RAID 5 parity information requires the space of a single disk in the array or can be computed using the formula

    (N1)*S = T

    where N is the number of disks, S is the size of the allocated space on each disk, and T is the total available space for storage. For example, if five disks allocate 10GB each for a RAID 5 array, the total available disk space available for storage will be (51)*10GB = 40GB. The 10GB are reserved for parity information.

  • Mirrored volume Mirrored or RAID 1compatible volumes require two separate disks, and the space allocated on each disk must be equal. Mirrored sets duplicate data across both disks and can withstand a single disk failure. Because the mirrored volume is an exact replica of the first disk, the space capacity of a mirrored set is limited to half of the total allocated disk space.

Tip

As a best practice, try to provide disk fault tolerance for your operating system and data drives, preferably using hardware-based RAID sets.

For the rest of this chapter, both basic partitions and dynamic volumes will be referred to as volumes.

Disk Formatting

Windows Server 2003 supports formatting basic and dynamic volumes using the NTFS, FAT, or FAT32 file system. FAT volumes are supported by MS-DOS and all Microsoft Windows operating systems, but should be limited to 2GB if MS-DOS access is necessary. FAT32 was first supported by Microsoft with Windows 95, but these partitions cannot be read by MS-DOS, Windows for Workgroups, or Windows NT. Windows Server 2003 NTFS volumes are supported by Windows NT 4.0 with Service Pack 6a or higher and all versions of Windows 2000, Windows XP, and Windows Server 2003. File shares can be created on each type of disk format, but NTFS volumes provide extended features such as volume storage quotas, shadow copies, data compression, file- and folder-level security, and encryption.

Managing Disks

Disks in Windows Server 2003 can be managed using a variety of tools included with the operating system. Disk tasks can be performed using the Disk Management Microsoft Management Console (MMC) snap-in from a local or remote server console or using a command-line utility called diskpart.exe.

Using the Disk Management MMC Snap-in

Most disk-related administrative tasks can be performed using the Disk Management MMC snap-in. This tool is located in the Computer Management console, but the stand-alone snap-in can also be added in a separate Microsoft Management Console window. Disk Management is used to identify disks, define disk volumes, and format the volumes. Starting in Windows Server 2003, the Disk Management console can be used to manage disks on remote machines. If a disk is partitioned and formatted during the Windows Server 2003 setup process, when installation is complete, the disk will be identified as a basic disk. After Windows Server 2003 is loaded and disk management can be accessed, this disk can be converted to a dynamic disk, giving server administrators more disk configuration options.

Using the Diskpart.exe Command-Line Utility

Diskpart.exe is a functional and flexible command-line disk management utility. Most disk tasks that can be performed using the Disk Management console can also be performed using this command-line utility. Using diskpart.exe, both basic volumes and dynamic volumes can be extended, but Disk Management can extend only dynamic volumes. Diskpart.exe can be run with a script to automate volume management.

As a sample of scripting diskpart.exe, using a filename like c:\drive info.txt, the following information can be used to extend a volume using unallocated space on the same disk:

Select Volume 2
Extend
Exit

When you're creating the command script file, be sure to press Enter at the end of each command so that when the script is called out, the Enter keystroke is executed.

At the command prompt, run

Diskpart.exe /s c:\drive_info.txt

Now volume 2 will be extended with all the remaining unallocated disk space on the same disk.

Note

If you want to extend a basic volume using diskpart.exe, the unallocated disk space must be on the same disk as the original volume and must be contiguous with the volume you are extending. Otherwise, the command will fail.

Creating Fault-Tolerant Volumes

Windows Server 2003 supports fault-tolerant disk arrays configured and managed on a RAID disk controller or configured within the operating system using dynamic disks. To create arrays using a RAID controller, refer to the manufacturer's documentation and use the appropriate disk utilities. Software-based RAID can be configured using the Disk Management console or the command-line utility diskpart.exe.

Converting Basic Disks to Dynamic Disks

Before an administrator can create software-based fault-tolerant volumes, the necessary disk must be converted to a dynamic disk. To convert a basic disk to a dynamic disk, follow these steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Click Start, All Programs, Administrative Tools, Computer Management.
3. | In the left pane, if it is not already expanded, double-click Computer Management (local).
4. | Click the plus sign next to Storage.
5. | Select Disk Management.
6. | In the right pane, verify that the disk containing the system volume is marked as dynamic.
7. | If each of the necessary disks is already dynamic, close Computer Management by selecting File, Exit.
8. | If the drive is marked as basic, right-click the drive and select Convert to Dynamic Disk. Select the appropriate disk, press OK, verify the information in the dialog box, and then click Convert.
9. | Repeat the preceding steps for each disk that will participate in a spanned, mirrored, striped, or RAID 5 volume.
10. | If the disk containing the system drive is converted, the operating system may request multiple system reboots to first unmount the drive and then to convert it to a dynamic disk. After you restart, the disk will be recognized as a new disk, and another reboot will be necessary. Reboot the system as requested.
11. | After all necessary disks are converted to dynamic, use Disk Management in the Computer Management console to verify that the conversion was successful and the disks can still be accessed.
Creating Fault-Tolerant Disk Volumes Using Dynamic Disks

Creating a fault-tolerant disk volume in Windows Server 2003 requires having two disks available for a mirrored volume and at least three disks for a RAID 5 volume. To create a mirrored system volume, follow these steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Click Start, All Programs, Administrative Tools, Computer Management.
3. | In the left pane, if it is not already expanded, double-click Computer Management (local).
4. | Click the plus sign next to Storage.
5. | Select Disk Management.
6. | In the right pane, right-click the system volume and choose Add Mirror.
7. | If more than one additional dynamic disk is available, choose the disk on which to create the mirror for the system volume and click Add Mirror.
8. | The volumes on each disk start a synchronization process that may take a few minutes or longer, depending on the size of the system volume and the types of disks being used. When the mirrored volume's status changes from Resynching to Healthy, select File, Exit in the Computer Management console to close the window.
9. | Log off the server console.

A Windows Server 2003 RAID 5 volume requires three separate dynamic disks, each containing an equal amount of unallocated disk space for the volume. To create a RAID 5 volume using Disk Management, follow these steps:

1.
Log on to the desired server using an account with Local Administrator access.

2.
Click Start, All Programs, Administrative Tools, Computer Management.

3.
In the left pane, if it is not already expanded, double-click Computer Management (local).

4.
Click the plus sign next to Storage.

5.
Select Disk Management.

6.
Right-click Disk Management and select New, Volume.

7.
Click Next on the New Volume Wizard Welcome screen.

8.
On the Select Volume Type page, select the RAID 5 radio button and click Next to continue.

9.
On the Select Disks page, select a disk that will participate in the RAID 5 volume from the Available pane and click the Add button.

10.
Repeat the preceding steps for the two or more remaining disks until all the participating disks are in the Selected pane.

11.
After all the disks are in the Selected pane, the maximum available volume size is automatically calculated, as displayed in Figure 30.1. Click Next to continue, or enter the correct size in megabytes and then click Next.

Figure 30.1. Configuring the RAID 5 volume's storage capacity.

[View full size image]

12.
On the Assign Drive Letter or Path page, choose the drive letter to assign this volume. Other options include not assigning a drive letter to the volume and mounting the volume in an empty NTFS folder in a separate volume. Choose the option that meets your requirements and click Next to continue.

13.
On the Format Volume page, choose whether to format the volume and enable data compression. Click Next to continue.

Tip

When you're formatting RAID 5 volumes, perform a complete format to avoid loss of disk performance later when data is first copied to the volume.

14.
Click Finish on the Completing the New Volume Wizard page to create the volume and start the format.

15.
The volume is then formatted, which can take a few minutes. When the formatting starts, you can close the Computer Management console and log off the server.

16.
When prompted to restart your server, choose whether you want to restart the system now by selecting Yes or restart the system at a different time by selecting No.

Tip

Before you start using the volume, you should check it for health using the Disk Management MMC snap-in.


Managing File Share Access and Volume Usage

Managing access to file shares and data can be relatively simple if the administrator understands each of the options available in Windows Server 2003. Windows Server 2003 provides several tools and services that can make securing data access simple. The security options for files and folders on a volume are directly related to the file system format of that volume and the method by which the data is accessed. For example, a FAT- or FAT32-formatted volume cannot secure data at the file and folder level, but an NTFS volume can.

Using a FAT volume, administrators do not have many options when it comes to managing data access from the network. The only option that can be configured is setting permissions on the file share. The end user's access is granted or denied using only the file share permissions that apply to every file and folder within.

NTFS volumes provide several data access options such as share permissions just like FAT volumes, but also file- and folder-level security; and to manage data usage, user-based quotas can be configured on a volume. The user quota determines how much data a single end user can store on a volume. NTFS volumes can also be managed by Remote Storage to automatically archive data to remote media when it hasn't been accessed for an extended period of time or when a drive reaches a capacity threshold that triggers file migration or archiving.

Managing File Shares

File shares can be created on FAT, FAT32, and NTFS volumes. When a file share is created, share optionsincluding the share name, description, share permissions limiting the number of simultaneous connections, and the default offline file settingscan be configured. There are many ways to create a share, but in the following example, you will use the Share a Folder Wizard.

To create and configure a file share, follow these steps:

1.
Log on to the desired server using an account with Local Administrator access.

2.
Click Start, All Programs, Administrative Tools, Computer Management.

3.
In the left pane, if it is not already expanded, double-click Computer Management (local).

4.
Click the plus sign next to System Tools and then click the plus sign next to Shared Folders.

5.
Right-click the Shares icon and choose New Share.

6.
After the Share a Folder Wizard opens, click Next on the Welcome screen.

7.
Enter the path of the folder you want to share and click Next to continue.

8.
If you don't know the folder path or it does not exist, click the Browse button to locate the correct drive letter and select or create the folder. Then click OK to create the path and click Next on the Folder Path page to continue.

9.
On the Name, Description, and Settings page, enter the share name, description, and offline settings, as displayed in Figure 30.2.

Figure 30.2. Entering the file share configurations.

[View full size image]

10.
The default offline settings allow the end users to designate whether to synchronize share data locally. Accept the default settings or change the offline settings option by clicking the Change button, selecting the appropriate radio button, and clicking OK. Click Next to continue.

11.
On the Permissions page, specify which permissions configuration option suits the needs of the share. The default is to allow read-only access to everyone. Select the correct radio button and click Finish. If custom share permissions are required, click the Customize button, create the permissions, and click Finish on the Permissions page when you're done.

12.
If sharing was successful, the next page displays the summary. Click the Close button.

13.
Back in Computer Management, right-click the new share in the right pane and select Properties.

14.
On the General tab, configure the user limit.

15.
If the server is a member of an Active Directory domain, you can select the Publish page and publish the share in Active Directory. To do so, use a description and keywords to locate the share by querying Active Directory.

16.
If the shared folder resides on an NTFS volume, a Security page is displayed. Set the permissions appropriately for the shared directory.

17.
After all the pages are configured, click OK on the Share Properties page to save changes.

18.
Close Computer Management and log off the server.

As a best practice, always define share permissions for every share regardless of the volume format type. When a share is first created, the default permission is set to grant the Everyone group read permissions. This may meet some share requirements for general software repositories, but it is not acceptable for user home directories, public or shared data folders, or shares that contain service logs that will be updated by remote systems.

The level of permission set at the share level must grant enough access to enable users to access their data and modify or add more data when appropriate.

Tip

As a general guideline, when shares are created on domain servers and anonymous or guest access is not required, replace the Everyone group with the Domain Users group and set the share permissions accordingly.

Client-Side Caching

To improve the reliability and availability of shared folders, NTFS partitions allow users to create local offline copies of files and folders contained within a file share. The feature is called client-side caching (CSC), but the common name for such files is offline files. Offline files are stored on a local user's machine and are used when the server copy is not available. The offline files synchronize with the server at logon, logoff, and when a file is opened or saved.

Offline files can be configured on a per-share basis using the shared folder's share property page. To configure client-side caching or offline file options, perform the following steps:

1.
Log on to the desired file server with Local Administrator access.

2.
Click Start, My Computer.

3.
Double-click the drive containing the shared folder.

4.
Locate the shared folder, right-click it, and select Sharing and Security.

5.
Click the Offline Settings button at the bottom of the page.

6.
Select the appropriate offline settings, as displayed in Figure 30.3, and click OK to close the Offline Settings window.

Figure 30.3. Granting users the right to define offline file and folder settings.

7.
Click OK in the Folder window to apply the changes, close the window, and log off the server.

Caution

If roaming user profiles are used on a network, do not enable client-side caching on the file share because doing so may corrupt the end user's profile. By default, roaming user profiles are already copied down to the local server or workstation when the user logs on. Forcing the folder to synchronize with the server may cause user settings to be lost. User profile management can be configured using Group Policy. The settings are located in Computer Configuration\ Administrative Templates\System\User Profiles.


Leveraging the Capabilities of File Server Resource Manager

With the release of Windows 2003 R2, Microsoft added a new component that provides better quota and storage management of files in a Windows 2003 environment. File Server Resource Manager, or FSRM, is a technology that enables administrators to set storage quota limits as well as identify and enforce data storage policies.

Unlike quota functions in other operating systems that allow administrators to set quotas for the storage of just file data on servers, FSRM provides more flexibility in the way it allows files to be managed. For example, in typical file quota processes, an administrator may set the storage limit for users to be 100MB. That's fine for the typical user who commonly writes memos or small documents; however, in a highly collaborative environment, a manager may be responsible for viewing and editing all documents created in the organization. As the final editor of all documents, the manager will exceed his 100MB limit because he will frequently open and save files that he edits. So the organization changes the manager's quota, typically to an unlimited storage amount. This violates the company policy of limiting storage because this manager now no longer has a storage limit.

FSRM allows administrators to still enforce the 100MB limit on the manager for personal files, but can waive storage limits for all files the manager opens and saves to a specific branch of the filesystem, such as a shared folder or a data directory to which edited documents are commonly saved. This allows the manager to continue to perform his job of editing and saving shared documents, but still enforces the organizational 100MB limit on all other files.

However, this too creates a hole in the organization's file storage limit process. Therefore, FSRM includes yet another feature that prevents this manager from potentially overstepping his rights of unlimited shared storage, by allowing administrators to add a file type limit. If the users are storing only shared Word documents and Excel spreadsheets for review and edits, then the administrator can specify an unlimited storage of *.doc and *.xls file types in the shared folder, and block the saving of files that are not .doc or .xls files, such as MP3 audio files or MPG video files.

Multiple policies and filters can be added to folders, users, and groups of users to allow, disallow, enable, or disable the users' abilities to store files, certain file types, or other designations to help the administrator best manage and administer the environment.

Uses of File Server Resource Manager

When administrators are initially introduced to File Server Resource Manager, they immediately think about setting and enforcing storage quotas to limit users on the amount of disk space they can access. However, in production environments, several practice uses of FSRM functionality have drastically simplified administration and management functions for a network. The most common uses of FSRM are as follows:

  • Setting Limits on User Storage An administrator can set the limit on how much disk space a user or group of users can store on a system. This is the traditional quota limit item that can limit users to store, say, 100MB of files on the network.

  • Providing Flexibility of Group Storage When a user or group of users need to have different storage limits, instead of allowing these users unlimited access, FSRM can be configured to allow the extension of storage usage beyond the default for specific file types (that is, *.doc or *.xls files) or file locations (for example, shared storage locations or public posting areas of the network).

  • Enforcing Storage Policies FSRM does more than just define storage policies; it helps administrators enforce the policies by creating reports and generating notifications of policy violations on a real-time basis.

Installing the File Server Resource Manager Component

The File Server Resource Manager is a component within the Windows 2003 R2 update. To install the File Server Resource Manager component, the Windows 2003 R2 components must be installed on the system (see the section, "Preparing a System and Installing the Windows 2003 R2 Components," in Chapter 3 for installation instructions). Perform the following steps to enable the File Server Resource Manager component option on the system:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Select Start, Settings, Control Panel, Add/Remove Programs.
3. | Click Add/Remove Windows Components, and double-click the Management and Monitoring Tools folder. Select the File Server Resource Manager component and click Next.
4. | Click Next to install the component, and then click Finished when you're done. Typically, you will be required to restart the server in order for FSRM to be enabled.

Configuring User Storage Limits with File Server Resource Manager

After the File Server Resource Manager component has been enabled on a server, an administrator can launch the utility and begin creating FSRM policies. To open the FSRM utility, do the following:

1. | Select Start, Settings, Control Panel.
2. | Open the Administrative Tools folder and double-click File Server Resource Manager to launch the FSRM Component.

When you open the FSRM component, a screen will appear similar to the one shown in Figure 30.4.

Figure 30.4. File Server Resource Manager utility in Windows 2003 R2.

[View full size image]

To create a simple quota within the File Server Resource Manager utility, do the following:

1.
Click the Create Quota action item in the far right pane of the FSRM utility, or click Action, Create Quota from the menu bar.

2.
Specify the path for the quota, such as c:\Home Directory.

3.
Choose the option Create Quota on Path to create a new quota, or choose Auto Apply Template and Create Quotas on Existing and New Subfolders if you have created a quota template (more on quota templates in the next section, "Creating a Quota Template").

4.
Specify the storage limit quota from one of the quota property templates, or create a custom quota limit.

5.
View the quota designation in the Summary screen, as shown in Figure 30.5, and click Create to create the quota.

Figure 30.5. Creating a quota from the Create Quota action item.

[View full size image]

After the quota has been created, the quota shows up on the Quotas folder in the Quota Management section of the FSRM utility. An administrator can choose to view, edit, or delete the defined quota.

Creating a Quota Template

When working with quotas, rather than defining the storage limits on each folder being issued a quota, an administrator can create a quota template and apply the template to the folder, simplifying the quota policy creation process. Within the quota template, the administrator can define the following:

  • Amount of Disk Space of the Quota The administrator can define in KB, MB, GB, or TB the amount of space to be set as the quota for the template.

  • Hard Limit or Soft Limit A hard limit does not allow a user to extend beyond the hard limit for storage, whereas a soft limit gives the user a warning that they have exceeded the policy limit. However, it allows the user to continue to save files beyond the limit.

  • Notification Thresholds When the storage limit nears or reaches the quota limit, a series of events can occur. For example, an automatic email warning, event log, or script can be generated and executed. The various nofication threshold options are shown in Figure 30.6.

Figure 30.6. Threshold settings for a quota template.

To create a template, click the Quota Templates item of the Quota Management section of the FSRM utility, and then follow these steps:

1.
Click the Create Quota Template action item in the far right pane of the FSRM utility, or click Action, Create Quota Template from the menu bar.

2.
Give the quota template a name, such as 250MB Limit for Execs.

3.
Specify the storage limit for the quota in KB, MB, GB, or TB. In this example, you would enter 250 and choose MB from the list.

4.
Pick whether you want a hard limit or soft limit for the quota.

Note

To properly create a storage policy, hard limits should be used as the default. This will ensure the policy is being enforced. However, many organizations choose to identify certain quota policies with soft limits based on organizational politics (for example, allow executives in the organization, or the legal department, to exceed the limit through the use of soft quota limits).

5.
Create notification thresholds by clicking the Add button and defining limits. Some of the common thresholds are an 85% limit that notifies users when they have achieved 85% of their limits and to consider deleting files so they do not exceed their limits.

6.
The quota limit will look something like Figure 30.7. Click OK when you're satisfied with your settings.

Figure 30.7. Quota template settings.

The administrator can now create quotas and apply this template or other templates to the quota settings.

Creating File Screens

Another function of the File Server Resource Manager is the capability to create file screens. A file screen is a form of storage limit that looks at the file type being stored and either allows or disallows a user from saving certain file types. As an example, an organization can allow the storage of *.doc Word documents and *.xls Excel spreadsheets and deny the storage of *.mp3 audio files and *.mpg video files to a given storage area.

To create a file screen within the File Server Resource Manager utility, click the File Screens option in the File Screen Management section of the FSRM utility. Then do the following:

1.
Click the Create File Screen action item in the far right pane of the FSRM utility, or click Action, Create File Screen from the menu bar.

2.
Specify the path for the file screen, such as c:\Home Directory.

3.
Choose the option Derive Properties from the File Screen Template, or choose Define Custom File Screen Properties depending on whether you want to apply a template or create a custom screen (more on file screen templates in the following section, "Creating a File Screen Template").

4.
View the file screen designation in the summary screen, as shown in Figure 30.8, and click Create to create the file screen.

Figure 30.8. Creating a file screen from the Create File Screen action item.

After the file screen has been created, it shows up on the File Screens folder in the File Screens Management section of the FSRM utility. An administrator can choose to view, edit, or delete the defined file screen.

Creating a File Screen Template

When working with file screens, rather than defining the file type limits on each folder being issued a file screen, an administrator can create a file screen template and apply the template to the folder, simplifying the file screen creation policy process. Within the file screen template, the administrator can define the following:

  • File Groups The administrator can define the file types into groups, such as an Office files group containing *.doc Word files and *.xls spreadsheet files, or a Audio and Video files group containing *.wav and *.mp3 audio files and *.mpg and *.vob video files.

  • Active Screening and Passive Screening An active screen does not allow a user to save the file types designated. A passive screen will notify the user that the file type storage is not permitted but allows the user to proceed with saving the file type.

  • Notification When a user attempts to save a file that matches the file screen designation, a notification can be generated. The notification can be the automatic generation of an email warning or an event log, or a script can be executed.

To create a file screen template, click the File Screen Templates item of the File Screen Management section of the FSRM utility, and then do the following:

1. | Click the Create File Screen Template action item in the far right pane of the FSRM utility, or click Action, Create File Screen Template from the menu bar.
2. | Give the file screen template a name, such as No Video Files.
3. | Pick whether you want an active screen or a passive screen for the quota. Note To properly create a file screen policy, active screens should be used as the default. This will ensure that the policy is being enforced. However, many organizations choose to identify certain file screen policies with passive filtering based on organizational politics (that is, allow executives in the organization, or the marketing department, to store files that otherwise violate the file screen policy).
4. | Create email message, event log, command, and report notification settings to alert those who want to be alerted when a file screen policy has been violated.
5. | Click OK to create the file screen template.

The administrator can now create file screen policies and apply this template or other templates to the file screen settings.

Generating Storage Reports from FSRM

The File Server Resource Manager provides the capability to create or automatically generate reports for quota and file screen activity. The various reports that can be generated include

  • Duplicate Files

  • File Screening Audit

  • Files by File Group

  • Files by Owner

  • Large Files

  • Least Recently Accessed Files

  • Most Recently Accessed Files

  • Quota Usage

Generating Reports in Real Time

Reports can be generated on a real-time basis to view the file storage information on demand. To generate a report, right-click the Storage Reports Management option of the FSRM utility and choose Generate Report Now. Then do the following:

1. | Click Add to choose the volume or file share that you want to generate a report, such as c:\Home Directory.
2. | Choose what you want to report on, such as duplicate files, file screening audit, or files by file group.
3. | Choose the report format you want to generate the report, whether it is DHTML, HTML, XML, CSV, or Text. Note Typically, reports are generated in HTML format so the administrator can view the report out of any browser. However, if the report will be posted on a web server so others can view it, the DHTML or XML format will provide a more versatile report-viewing format. Additionally, the CSV file format can generate a report that can be imported into a spreadsheet or database for data or trend analysis. And text format is commonly used when a unformatted display of information is desired.
4. | Click OK when finished.

The report or reports specified will be generated and displayed onscreen. The reports can be printed, or the reports can be saved for view or analysis at a later date.

Scheduling Reports to Be Generated on a Regular Basis

Reports can be generated on a regular basis (such as weekly or monthly), typically for the purpose of reporting file storage information to management. To schedule a report, right-click the Storage Reports Management option of the FSRM utility and choose Schedule a New Report Task. Then do the following:

1. | Click Add to choose the volume or file share that you want to generate a report, such as c:\Home Directory.
2. | Choose what you want to report on, such as duplicate files, file screening audit, or files by file group.
3. | Choose the report format you want to generate the report, whether it is DHTML, HTML, XML, CSV, or Text.
4. | Choose Delivery and specify the user name of the individual to whom you want the report to be delivered. This may be the administrator account or an auditor's account.
5. | Define a schedule if you want the report to be automatically generated and sent. This option is commonly used by organizations that want to generate weekly or monthly reports that are analyzed and reported regularly to management.
6. | Click OK when finished.

The report or reports specified will be generated at the scheduled time and the individual designated in the report form will be notified when the report has been completed.


Monitoring Disks and Volumes

If a server administrator can monitor only a handful of resources on a server, disks and volumes should be included. Using System Monitor in the Performance console, both physical disks and logical disks (volumes) can be monitored.

Managing Volume Usage with NTFS Quotas

On NTFS volumes only, quotas can be enabled to manage the amount of data a user can store on a single volume. This capability can be useful for volumes that contain user home directories and when space is limited. Quota usage is calculated by the amount of data a particular user created or owns on a volume. For example, if a user creates a new file or copies data to his home directory, he is configured as the owner of that data, and the size is added to the quota entry for that user. If the system or the administrator adds data to the home directory for a user, that data is added to the administrator's quota entry, which cannot be limited. This is usually where administrators get confused because a user's folder may be 700MB on a quota-managed volume, but the quota entry for that user reports only 500MB used. The key to a successful implementation of quotas on a volume is setting the correct file permissions for the entire volume and folders.

As explained in the earlier section titled "Leveraging the Capabilities of File Server Resource Manager," FSRM also provides the capability to set quotas on storage limits. The difference between FSRM quotas and NTFS quotas are shown in Table 30.1.

Table 30.1. FSRM and NTFS Quota Differences

Quota Capabilities

FSRM Quotas

NTFS Quotas

Quota tracking

By folder or by volume

Per user on a specific volume only

Calculation of storage usage

By actual disk space used

By the logical file size on the volume

Notification Method

By email, custom reports, reports, and event log entries

By event log only

Note

Prior to the release of FSRM, organizations used to depend on NTFS quotas for their quota storage management capabilities. However, FSRM has effectively replaced the use of NTFS quotas. The coverage of NTFS quotas in this section is merely to describe the process and use of NTFS quotas. Most organizations should consider using FSRM quotas in the Windows 2003 R2 update as the best practice method of creating and enforcing storage quotas.

To enable quotas for an NTFS volume, follow these steps:

1.
Log on to the desired server using an account with Local Administrator access.

2.
Click Start, My Computer.

3.
Locate the NTFS volume on which the quota will be enabled.

4.
Set the appropriate permission to ensure that users have the right to write data only where it is necessary and in no other location. For example, a user can write only to her home directory and cannot read or write to any other directory.

5.
Right-click the appropriate NTFS volume and select Properties.

6.
Select the Quota tab and check the Enable Quota Management box.

7.
Enter the appropriate quota limit and warning thresholds and decide whether users will be denied write access when the limit is reached, as shown in Figure 30.9.

Figure 30.9. Configuring a quota limit.

8.
Click OK to complete the quota configuration for the NTFS volume.

9.
When prompted whether you want to enable the quota system, select Yes; otherwise, to cancel the configuration, click Cancel.

10.
After you configure quotas on all the desired NTFS volumes, close the My Computer window and log off the server.

To review quota entries or to generate quota reports, you can use the Quota Entries button on the Quota tab of the desired NTFS volume. Also, as a best practice, try to enable quotas on volumes before users begin storing data in their respective folders.

Using the Performance Console to Monitor Disks and Volumes

Using the Performance console from the Administrative Tools menu, a server administrator can monitor both physical disks for percent of read and write times as well as logical disks for read and write times, percent of free space, and more. Using performance logs and alerts, an administrator can configure a script to run or a network notification to be sent out when a logical disk nears a free space threshold.

Using the Fsutil.exe Command-Line Utility

The Fsutil.exe tool can be used to query local drives and volumes to extract configuration data such as the amount of free space on a volume, quota enforcement, and several other options. In many environments, this tool is not used much, but it can be useful when managing disks from a command-line interface if necessary. For example, Fsutil.exe may be a great tool for checking volume status when managing the server through a remote shell, remote command prompt window, or a Telnet window.

Auditing File and Folder Security

Auditing allows an administrator to configure the system to log specified events in the security event log. Auditing can be configured to monitor and record logon/logoff events, privileged use, object access, and other tasks. Before a folder can be audited, auditing must be enabled for the server.

Audit settings for a server can be configured using the Local Security Settings console, or in an Active Directory domain, the audit settings can be configured and applied to a server from a Group Policy. To enable file and folder auditing for a server, the administrator should enable the Audit Object Access setting using Group Policy or the local security policy, as shown in Figure 30.10.

Figure 30.10. Enabling auditing of object access to log successful and failed attempts.

[View full size image]

Enabling Auditing for an NTFS Folder

When object access auditing is enabled for a server, the administrator can then configure the audit settings for a particular file or folder object. To enable auditing on a folder, follow these steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Click Start, My Computer.
3. | Locate the NTFS volume that contains the folder to audit.
4. | Locate the folder, right-click it, and select Properties.
5. | Select the Security tab and click the Advanced button.
6. | Select the Auditing tab and click Add to create a new audit entry.
7. | Enter the name of the user or group for which you will audit events and click OK. For example, enter Everyone to audit object access for this folder for anyone belonging to the Everyone group.
8. | Select the object access to audit and whether to audit successful attempts, failed attempts, or both.
9. | Click OK when you're finished.
10. | Add any additional users or groups, and when you're finished, click OK to close the Advanced Security Settings page.
11. | Click OK to close the Folder Properties page.

Access settings commonly audited include failed read attempts and successful and failed deletion of files, folders, and subfolders.

Reading Audit Events Using the Event Viewer Security Event Log

The server administrator can use the security event log to review audit entries. When the administrator becomes familiar with the audit event IDs, event log filters can be created to make collecting audit data easier.

Reviewing NTFS Volume Quota Usage

When an NTFS volume has quotas enabled, the server administrator should periodically check the volume's quota usage statistics. This can be accomplished using the Quota Entries console, which is accessible through the Quota Entries button on the Quota tab of the volume's property page.

To review NTFS quotas, follow these steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Click Start, My Computer.
3. | Locate the NTFS volume that quotas has been enabled on.
4. | Right-click the appropriate NTFS volume and select Properties.
5. | Select the Quota tab and click the Quota Entries button.
6. | In the Quota Entries window, review or modify a particular user's or group's quota settings as necessary.
7. | Close the Quota Entries window when you're finished.
8. | Close the volume's property page, close the My Computer window, and log off the server when you're finished reviewing quota information from the desired quota-enabled volumes.


Working with Operating System Files: Fault Tolerance

Microsoft has made great strides in the reliability and performance associated with its Windows-based server and workstation platforms. This holds true today for Windows Server 2003. When servers are built using only hardware displaying the Designed for Windows Server 2003 logo, server failures due to driver conflicts or overwritten system files are relatively rare. To produce a reliable operating system that does not tolerate attempts to overwrite system files or allow the installation of hardware drivers that have not been certified to work with Windows Server 2003, Microsoft has created Windows File Protection to provide system file and hardware driver fault tolerance.

Windows File Protection

Windows File Protection has been designed to protect essential system files from being overwritten by third-party software manufacturers or by viruses. Each original system file has a unique Microsoft digital signature that is recognized by Windows File Protection. When a program attempts to overwrite a protected system file, the new file is checked for a Microsoft digital signature, version, and content; then either it is rejected or the existing file is replaced.

Windows File Protection runs silently in the background and is used when an attempt to overwrite a system file is detected or when a system file has already been overwritten and needs to be replaced by a cached copy of the original system file. Windows File Protection restores the file from a DLL cache, if one has been created, or a pop-up window asking for the Windows Server 2003 CD will appear on the local server console. Currently, only the original operating system files, Microsoft service packs, and Microsoft patches and hotfixes contain a Microsoft digital signature. Hardware vendors who certify their hardware after a platform release date may offer certified drivers on their Web sites.

Windows File Protection uses digital signatures or driver signing to identify and validate system files. When the system files need to be scanned or have a file replaced, the task can be carried out by using the File Signature Verification tool and the System File Checker tool. When the level of driver security needs to be configured, administrators can use the driver signing options of the server's system property pages.

Driver Signing

Windows Server 2003 allows an administrator to control the level of security associated with hardware drivers. Because Microsoft works closely with Independent Hardware Vendors (IHVs), Windows Server 2003 and Windows XP support extensive brands of hardware and server peripherals. When an IHV tests its hardware and passes certain Microsoft requirements, its hardware driver is certified, digitally signed by Microsoft, and in most cases, added to the Hardware Compatibility List (HCL) for the particular platform or operating system.

To configure the security level of driver signing, perform the following steps:

1.
Log on to the desired server using an account with Local Administrator access.

2.
Click Start, Control Panel, System. If the Control Panel does not expand in the Start menu, double-click the Control Panel icon and double-click the System icon.

3.
On the System Properties page, select the Hardware tab.

4.
In the Device Manager section of the Hardware tab, click the Driver Signing button.

5.
Select the driver signing option that best suits your hardware and reliability needs, as shown in Figure 30.11.

Figure 30.11. Selecting driver signing options.

6.
Click OK to exit the Driver Signing Options page and click OK again to exit the System Properties page.

Windows Hardware Quality Lab

The Windows Hardware Quality Lab is the place where hardware is tested before it can receive the Designed for Windows logo. IHVs can send their hardware or actually go to the lab to test their hardware to have it certified and have the driver digitally signed by Microsoft. With Microsoft providing the environment for IHVs to test and certify their hardware, organizations can expect more dependable service from Microsoft servers running on several different hardware platforms. This gives organizations many options when they need to choose a server vendor or a specific hardware configuration. A Windows Server 2003 system that uses only certified hardware will be fully supported by Microsoft when hardware or software support is needed.

File Signature Verification (Sigverif.exe)

File Signature Verification is a graphic-based utility that can be used when it is suspected that original, protected system files have been replaced or overwritten after an application installation. This tool checks the system files and drivers to verify that all the files have a Microsoft digital signature. When unsigned or incorrect version files are found, the information, including filename, location, file date, and version number, is saved in a log file and displayed on the screen.

To run this tool, choose Start, Run, and then type Sigverif.exe. When the window is open, click Start to build the current file list and check the system files.

System File Checker (Sfc.exe)

The System File Checker is a command-line tool that is similar in function to the File Signature Verification tool, but incorrect files are automatically replaced. Also, this command-line tool can be run from the command line, through a script, or from defined settings in Group Policy. The options include setting it to scan a system at startup, to scan only on the next startup, or to scan immediately. The default is that files are scanned during setup. The first time Sfc.exe is run after setup, it may prompt for the Windows Server 2003 CD to copy Windows system files to the DLL cache it creates. The cache is used to replace incorrect files without requiring the Windows Server 2003 CD.

Note

Sfc.exe scans and replaces any system files that it detects are incorrect. If any unsigned drivers are necessary for operation, do not run this utility; otherwise, the files may be replaced and cause your hardware to operate in ways you do not want.

Sfc.exe options are configurable using Group Policy with settings found in Computer Configuration\Administrative Templates\System\Windows File Protection.


Using the Distributed File System Replication

To improve the reliability and availability of file shares in an enterprise network, Microsoft has developed the Distributed File System. DFS improves file share availability by providing a single, unified namespace to access shared folders hosted across different servers. A user needs to remember only a single server or domain name and share name to connect to a DFS shared folder.

Note

As noted earlier in this chapter, with the release of Windows 2003 R2, Distributed File System is now called Distributed File System Replication, or DFSR. Because DFS and DFSR are commonly referenced interchangeably, this section of the chapter will also use the references DFS and DFSR interchangeably.

Benefits of DFSR

DFSR has many benefits and features that can simplify data access and management from both the administrator and user perspective. DFS inherently creates a unified namespace that connects file shares on different servers to a single server or domain name and DFS link name, as shown in Figure 30.12. Using Figure 30.12 as an example, when a user connects to \\SERVER2\UserData, he will see the software folder contained within. Upon opening this folder, the user's DFS client will redirect the network connection to \\Server99\downloads, and the user will remain unaware of this redirection.

Figure 30.12. A standalone DFS root with a link targeting a different server.

Because end users never connect to the actual server name, administrators can move shared folders to new servers, and user logon scripts and mapped drive designations that point to the DFS root or link do not need to be changed. In fact, a single DFS link can target multiple servers' file shares to provide redundancy for a file share. This provides file share fault tolerance; because clients will be redirected to another server, the current server becomes unavailable. The DFS client will frequently poll the connected server and can redirect the user connection if the current server becomes unavailable.

When a domain-based DFS root is created, the file shares associated with a link can be automatically replicated with each other. When users attempt to access a replicated DFS share, they will usually be connected to a server in the local Active Directory site but can connect to remote sites as needed. Before we discuss DFS any further, we should define some key terms used by the Distributed File System and the File Replication Service.

DFS Terminology

To properly understand DFS, you must understand certain terms that are commonly used in referencing DFS configurations. These terms, described next, are frequently used to refer to the structure of a DFS configuration, and at times, the terms are actually part of the DFS configuration.

  • DFS root The top level of the DFS tree that defines the namespace for DFS and the functionality available. DFS roots come in two flavors: standalone root and domain root. A standalone root can be accessed by the server name on which the root was created. The domain root can be accessed by the domain name that was specified when the root was created. A domain-based root adds fault-tolerant capabilities to DFS by allowing several servers to host a replica of a DFS link. See more detailed explanations later in this chapter.

  • DFS link The name by which a user connects to a share. You can think of a link as the DFS share name because this is the name users will connect to. DFS links redirect users to targets.

  • Target The actual file share that is hosted on a server. Multiple targets can be assigned to a single DFS link to provide fault tolerance. If a single target is unavailable, users will be connected to another available target. When domain-based DFS links are created with multiple targets, replication can be configured using the File Replication Service to keep the data across the targets in sync.

  • DFS tree The hierarchy of the namespace. For example, the DFS tree begins with the DFS root name and contains all the defined links below the root.

  • Referral A redirection that allows a DFS client to connect to a specified target. Disabling a target's referral keeps it from being used by clients. Target referral can be disabled when maintenance will be performed on a server.

FRS Terminology

DFS uses the File Replication Service to automatically replicate data contained in DFS targets associated with a single root or link on which replication has been configured. To understand the replication concepts, you must understand some key FRS terminology. Here are some important terms:

  • Replication The process of copying data from a source server file share to a destination server file share. The file shares are replicated through replication connections.

  • Replication connection The object that manages the replication between a source and destination server. The replication connection defines the replication schedule and the source and destination replication partners, for example. Each replication connection has only a single source and destination replication partner.

  • Replication partner A server that shares a common replication connection. The inbound replication partner receives data from a server specified in the replication connection. The outbound replication partner sends data to the replication partner specified in the replication connections.

  • Replica A server that hosts a file share in which FRS replication is configured.

  • Replica set All the servers that replicate a given file share or folder with one another.

  • Multimaster replication The process that occurs when any replica in a replica set updates the contents of a replicated shared folder. Every replica can be the master, and every replica can be a slave. FRS replication defaults to multimaster, but replication connections can be configured to provide master-slave replication.


Planning a DFS Deployment

Planning for a DFS implementation requires an administrator to understand the different types of Distributed File Systems and the features and limitations of each type. Also, the administrator must understand what tasks can be automated using DFS and what must be configured manually. For instance, DFS can create the file share for a root folder through a DFS Wizard, but it cannot configure file share options such as share permissions, user connection limits, and offline file settings. Also, DFS cannot manage the NTFS permissions set at the root or link target NTFS folder.

When an organization wants automated file replication, domain-based DFS can utilize Windows Server 2003 FRS to replicate shared folders. The administrator does not need to understand all the technical aspects of FRS to configure DFS replication, but he should understand how initial replication will handle existing data in a target folder.

Configuring File Share and NTFS Permissions for DFS Root and Link Targets

DFS is not currently capable of managing or creating share or NTFS permissions for root targets and link targets. This means that to ensure proper folder access, administrators should first configure the appropriate permissions and, if multiple targets exist, manually re-create the permissions on the additional targets. If multiple targets are used and the permissions are not exact, administrators may inadvertently grant users elevated privileges or deny users access completely. To prevent this problem, administrators should create the target file share and configure the share and NTFS permissions manually at the shared folder level before defining the share as a DFS target.

Choosing a DFS Type

As mentioned previously, DFS comes in two flavors: standalone and domain. Both provide a single namespace, but domain DFS provides several additional features that are not available in standalone DFS. The DFS features available in a DFS tree depend on the DFS root type.

Standalone DFS Root

A standalone DFS root provides the characteristic DFS single namespace. The namespace is defined by the server that hosts the root target. Standalone roots can support only a single root target, but an administrator can configure multiple link targets. Multiple link targets must be kept in sync manually because FRS replication is not an option. Standalone roots are normally deployed in environments that do not contain Active Directory domains.

Domain DFS Root

For an administrator to create a domain DFS root, the initial root target must be a member of an Active Directory domain. A domain DFS provides a single namespace that is based on the domain name specified when the root was created. Domain DFS can utilize FRS to replicate data between multiple root or link targets.

Planning for Domain DFS and Replication

When an organization wants to replicate file share data, administrators should create a domain-based DFS root. Within a domain-based DFS tree, replication can be configured between multiple targets on a single root or link. When multiple targets are defined for a root or link, DFS can utilize the FRS to create replication connection objects to automatically synchronize data between each target.

Tip

As a best practice, it's recommended not to replicate domain DFS roots; instead, replicate DFS links between link targets. To provide fault tolerance for the DFS root, simply define additional root targets that can each provide access to the DFS links.

Note

With Windows 2003 R2, DFS now provides the capability to perform automatic namespace fallback. This means that if a DFS server fails, the namespace will automatically redirect the user request to data to the nearest replica of the data. When a server that is closer to the user becomes available, the user will fall back to the copy of the data that is closest to him or her.

Initial Master

When replication is first configured using the DFS console and the Replication Wizard, the administrator can choose which target server will be the initial master. The data contained on the initial master is replicated to the remaining targets. For targets on servers other than the initial master, existing data is moved to a hidden directory, and the current folder is filled with the data contained only in the initial master shared folder. After initial replication is complete, the administrator can restore data moved to the hidden folder back to the working directory, where it can trigger replication outbound to all the other replicas in the replica set. As a best practice, when adding additional targets to a replica set, try to start with empty folders.

Using the File Replication Service

When replication is configured for DFS links, the File Replication Service (FRS) performs the work. Each server configured for replication is called a replica. Each replica has replication connections to one or many targets in the replica set. The replication connections are one way, either inbound or outbound, and are used to send updates of changed files on a target to other replicas, and if the change is accepted, the data is sent.

In a two-server replica set, server1 and server2, let's assume that server1 has an outbound connection to server2 and a separate inbound connection from server2. Each server uses these two connections to send updated data and to receive and process changes and file updates. When a file is changed on server1, the file change is recorded in the NTFS volume journal. FRS on server1 monitors the journal for changes, and when one is detected, a change order is sent to server2, including the updated filename, file ID, and last saved date. The ID of the file is created by FRS before initial replication or when a file is added to a replica share. When the change order is received by server2, it either accepts the change order and requests the changed file, or it denies the change and notifies server1. The changed file is imported into the staging directory when the change order is created. The file is compressed and prepared to send to the outbound partner, and a staging file is created. When the replication schedule next allows replication to occur, the staging file is sent to the staging folder on server2, where it is decompressed and copied into the target folder.

The Staging Folder

The staging folder is the location where an FRS-replicated share stores the data that will be replicated to other replicas with direct FRS connections. When replication is configured using the Configure Replication Wizard in DFS, the system defaults to creating the staging folder on a drive other than the target share drive. Because replication data will travel through this folder, the drive hosting the staging folder must have sufficient free space to accommodate the maximum size of the staging folder and should be able to handle the additional disk load.

The Pre-Install Directory

When replication is initiated, the source server sends a change order to the destination server and creates staging files in the local staging folder. If the destination server accepts the change order, the staging files are copied from the source server staging folder to the hidden folder called Do_NOT_REMOVE_NrFrs_PreInstall_Directory in the target directory.

Determining the Replication Topology

Windows Server 2003 DFS provides a number of built-in replication topologies to choose from when an administrator is configuring replication between DFS links; they're described next. As a general guideline, it may be prudent to configure DFS replication connections and a schedule to follow current Active Directory site replication topology connections or the existing network topology when the organization wants true multi-master replication.

Hub-and-Spoke

A hub-and-spoke topology is somewhat self-descriptive. A single target is designated as the replication hub server, and every other target (spoke target) replicates exclusively with it. The hub target has two replication connections with each spoke target: inbound and outbound. When the hub target is unavailable, all replication updates stop.

Full Mesh

Using a full mesh topology, each target has a connection to every other target in the replica set. This enables replication to continue between available targets when a particular target becomes unavailable. Because each target has a connection to every other target, replication can continue with as few as two targets.

Ring

In a ring topology, each server has only two connections: one inbound from a target and one outbound to a different target. Using this topology, replication can be slow because a replication update must complete on a target before the next target receives the replication data. When a target becomes unavailable, the ring is essentially broken, and replication may never reach other available targets.

Custom

Custom replication allows an administrator to define specific replication connections for each target. This option can be useful if an organization wants a hub-and-spoke topology, but with multiple hub targets, as shown in Figure 30.8.

Replication Latency

Latency is the longest amount of time required for a replication update to reach a destination target. When replication is enabled, a schedule should be defined to manage replication traffic. Using Figure 30.13 as an example, if the replication connection between each target server is 15 minutes, the replication latency is 30 minutes. The longest replication intervalspoke target to spoke target, such as replication from server A to server Cneeds to hop two connections that replicate every 15 minutes, totaling a maximum of 30 minutes for the update to reach server C.

Figure 30.13. Custom hub-and-spoke topology with multiple hub servers.

Previous Page
Next Page


Installing DFS

To install DFS, an administrator of a fileserver on the network needs to install the DFS component of Windows 2003 R2 onto a server. The component installation is as follows:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Select Start, Settings, Control Panel, Add/Remove Programs.
3. | Click Add/Remove Windows Components, and select the Distributed File System component. Note When you select the Distributed File System component, if you click the Details button, you will notice there are subcomponents that can be selected or deselected individually. The subcomponents are DFS Management, DFS Diagnostic and Configuration Tools, and DFS Replication Service. To take advantage of all the capabilities of DFS, keep all three components enabled as part of the installation process.
4. | Click Next to install the component, and then click Finished when done.

Creating the DFS Root File Share

In creating DFS in a Windows 2003 environment, the administrator must start by creating a DFS root. To create the root, the administrator requires Local Administrator access on the server hosting the root. If a domain root is being created, Domain Administrator permissions are also necessary.

A DFS root requires a file share. When the DFS root is created, the name is matched to a file share name. The wizard searches the specified server for an existing file share matching the DFS root name; if it does not locate one, the wizard will create the share.

As a best practice, the file share should be created and have permissions configured properly before the DFS root is created. Doing so ensures that the intended permissions are already in place. Because share and NTFS permissions are not managed through the DFS console, using the wizard to create the share is fine as long as the share and NTFS permissions are configured immediately following the DFS root creation.

To create a file share for a DFS root, follow the steps outlined in the "Managing File Shares" section earlier in this chapter.

Note

Using NTFS volumes is recommended for DFS root and link target file shares, to enable file- and folder-level security. Also, domain DFS links can be replicated only between file shares on NTFS volumes.

Creating the DFS Root

To create a DFS root, follow these steps:

1. | Click Start, All Programs, Administrative Tools, Distributed File System.
2. | Right-click Distributed File System in the left pane and select New Root.
3. | Click Next on the New Root Wizard Welcome screen to continue.
4. | Select the root type and click Next.
5. | If you chose a domain root, select the correct domain from the list, or type it in and click Next. (If you chose a standalone root, skip this step.)
6. | On the Host Server page, type in the fully qualified domain name of the server that will host the DFS root and click Next to continue. If necessary, click the Browse button to search for the server.
7. | On the Root Name page, enter the desired name for the root, enter a comment describing the root, and click Next. Note The initial DFS root name must match the name of the file share created previously. If the share does not exist, the wizard will prompt you to create a file share from an existing folder or a new folder. Although the wizard can simplify the process by automating this task, it does not provide a method of configuring permissions.
8. | Click Finish on the Completing the New Root Wizard page to create the root and complete the process.

Creating a DFS Link

Creating a DFS link is similar to creating the DFS root. A link can be created only to target already-existing shares. The recommendation is to create the file share on an NTFS folder, if possible, to enable file and folder security.

To create a file share for a DFS link, follow the steps outlined previously in "Managing File Shares." To create the link, follow these steps:

1.
Click Start, All Programs, Administrative Tools, Distributed File System.

2.
If the root you want to host the link is not already shown in the left pane, right-click Distributed File System and select Show Root.

3.
In the Show Root window, expand the domain and select the DFS root. Or, for a standalone root, type in the server and share name of the DFS root. Then click OK to open the DFS root.

4.
In the left pane, right-click the DFS root and select New Link.

5.
On the New Link page, enter the link name, path (UNC server and share name), any comments, and the caching interval and click OK to create the link. A sample configuration is shown in Figure 30.14.

Figure 30.14. Configuring a DFS link.

The caching interval is the amount of time a client will assume the target is available before the DFS client verifies that the target server is online.

Adding Additional Targets

Domain-based DFS supports adding multiple targets at the root and link levels. Standalone DFS supports only multiple link targets. To create additional root targets, follow these steps:

1. | Click Start, All Programs, Administrative Tools, Distributed File System.
2. | If the root you want is not already shown in the left pane, right-click Distributed File System and select Show Root.
3. | In the Show Root window, expand the domain and select the DFS root. Or, for a standalone root, type in the server and share name of the DFS root. Then click OK to open the DFS root.
4. | In the left pane, right-click the DFS root and select New Root Target.
5. | Enter the host server with the additional target file share and click Next. When you're creating additional root targets, the file share must already exist on the host server with the same name as the root.
6. | Click Finish in the Completing the New Root Wizard page to create the additional root target.

To create an additional link target, follow these steps:

1. | Open the DFS console and connect to the root you want, as outlined in the first step of the preceding section.
2. | Click the plus sign next to the DFS root shown and select the DFS link you want.
3. | Right-click the DFS link and select New Target.
4. | On the New Target page, enter the path to the server and share.
5. | The New Target page contains a check box labeled Add This Target to the Replication Set. Leaving this box checked will simply start the Configure Replication Wizard immediately after creating the target. Uncheck this box because replication will be handled next.
6. | Click OK to create the target.

Publishing DFS Roots in Active Directory

Domain-based DFS roots can be published in Active Directory to make locating the root much easier. After the root is published, it can be located by querying Active Directory for files and folders.

To publish a root in Active Directory, follow these steps:

1. | Open the DFS console and locate the root you want.
2. | Right-click the root and select Properties.
3. | Select the Publish tab and check the Publish This Root in Active Directory box.
4. | Enter the description, owner account name, and keywords used to locate the root and click OK when completed.
5. | Click OK to close the Properties page.

Best Practices for DFS Replication

Following best practices for DFS replication can help ensure that replication occurs as expected. Because file replication is triggered by a file version change or last-saved or modified time stamp, a standard file share may generate many replication changes, which can saturate the network bandwidth. To avoid such scenarios, follow as many of these suggestions as possible:

  • Start with an empty DFS root folder to keep from having to replicate any data at the root level. Also, this can simplify the restore process of a DFS root folder because it contains only links that are managed by DFS.

  • Do not replicate DFS roots because the roots will try to replicate the data in the root folders plus the data contained within the link targets. Replication is not necessary if the links are already replicating. Because the roots will not replicate for redundancy, deploy domain DFS roots and add additional root targets.

  • If possible, use DFS for read-only data. When data is being replicated, FRS always chooses the last-saved version of a file. If a group share is provided through a replicated DFS link and two employees are working on the same file, each on different replica targets, the last user who closes and saves the file will have his change(s) saved and replicated over the changes of other previously saved edits.

  • Replicate only during nonpeak hours to reduce network congestion. For replicating links that contain frequently changing data, this may not be possible, so to provide data redundancy in the unified namespace, create only a single target for that link and deploy it on a cluster file share. This provides server-level redundancy for your file share data.

  • Back up at least one DFS link target and configure the backup to not update the archive bit. Changing the archive bit may trigger unnecessary replication.

  • Thoroughly test server operating system antivirus programs to ensure that no adverse effects are caused by the scanning of files on a replicated DFS target.

  • Verify that the drive that will contain the staging folder for a replication connection contains ample space to accept the amount of replicated data inbound and outbound to this server.

Having a high number of read-write operations is not desirable because it causes heavy replication, and in a scenario like this, DFS replication should be performed during nonpeak hours.


Optimizing DFS

DFS should be tuned on each replica server using the DFS console. Using the DFS console, the administrator can optimize the replication schedules and connections for DFS targets. On each server, certain existing Registry settings can be optimized, or new settings can be added to change the characteristics or default values of file replication settings, to accommodate the data that is being replicated. These Registry entries include the maximum size of the staging folder. The default setting is 660MB; this value can be increased to 4.2GB.

To increase the staging folder size, update the value data of the Staging Space Limit in KB value in the HKEY_Local_Machine\SYSTEM\CurrentControlSet\Services\NtFrs\ Parameters Registry key. The value entered represents kilobytes. When calculating your limit, remember that 1MB is equal to 1,024KB, not 1,000.

The Windows Server 2003 Resource Kit contains additional tools to optimize FRS connections, and it also includes some DFS and FRS troubleshooting utilities.

Prestaging a New DFS Replica

Windows Server 2003 supports the prestaging of a new target for a replicating DFS link. This provides the ability to restore a copy of an existing replica to this target before replication is enabled. Consider this option when adding existing DFS replicas containing large amounts of data because performing a full replication could severely impact network performance. This process is fairly straightforward if the right tools are used.

To prestage a DFS replica, follow these steps:

1. | Back up a single target of a replicating DFS link using the Windows Server 2003 Backup utility (ntbackup.exe).
2. | On the new target server, create the folder and file share for the new DFS target and set permissions accordingly. Most likely, the share and root folder NTFS permissions on an existing target are correct, so the permissions for this new target should mimic the existing targets.
3. | Using the Windows Server 2003 Backup utility, restore the previously backed-up target data to the target folder on the new server using the Restore to Alternate Location option. For more information regarding restoring data to an alternate location using Windows Server 2003 Backup, refer to Chapter 33, "Recovering from a Disaster."
4. | Using the DFS console logged in with an account with the proper permissions, add this target to the link if it has not already been added.

If one of the predefined replication topology choices has been configured for this link (for example, hub-and-spoke, ring, or full mesh), the new target will be added to the replication immediately. If a customized replication topology was previously created, you must add the new target to the replication manually by creating new replication connections for it.

This process currently works only if the data is backed up and restored using Windows Server 2003 Backup. When the new target is added to the replication, all the restored files are moved into the pre-existing folder within the target. FRS then compares the files in the pre-existing directory with the information provided by the existing targets. When a file is identified to be the same file as on the existing target, it is moved out of the preexisting folder to the proper location in the target. Only files that have changed or been created since the backup are replicated across the network.


Managing and Troubleshooting DFS

DFS can be managed through the DFS console included in the Windows Server 2003 Administrative Tools program group. DFS standalone and domain roots can be shown and managed in a single DFS console window. The administrator can check DFS root and link targets for availability by checking the status of all targets for a particular link, as shown in Figure 30.15.

Figure 30.15. Checking the status of DFS link targets.

Monitoring FRS Using the System Monitor

DFS and FRS can be monitored using the System Monitor. Windows Server 2003 includes two performance objects to monitor the File Replication Service. These counters are

  • FileReplicaConn This object can be used to monitor the amount of network usage that file replication connections are utilizing. Also, this object can be used to monitor the number of connections FRS is opening and supporting at any given time.

  • FileReplicaSet This performance object can be used to monitor statistical information about a particular replica. Some counters include staging files generated, packets received in bytes, and kilobytes of staging space in use and available.

Monitoring FRS Using SONAR

SONAR is a GUI-based tool used to monitor FRS. It provides key statistics on the SYSVOL such as traffic levels, backlogs, and free space without modifying any settings on the computers it monitors. Before installing SONAR, ensure that the latest .NET Framework is installed. SONAR can be downloaded from http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/sonar-o.asp, and it is also a part of the Windows Server 2003 Resource Kit.

Note

It is recommended to run SONAR from a domain controller, but it can also be run from a Windows 2000 or higher member server. If you plan on running Sonar from a member server, copy the Ntfrsapi.dll file located in the %SystemRoot%\System32 directory from a domain controller. This file is required for SONAR to execute properly.

After downloading and installing the Sonar executable or running the executable from the Windows Server 2003 Resource Kit, select the domain, replica set, and refresh rates as shown in Figure 30.16. You can then begin the monitoring by selecting View Results or optionally load a predefined query to run. More information on SONAR and troubleshooting FRS can be found in the Windows Server 2003 Resource Kit as well as the troubleshooting FRS whitepaper included with the download.

Figure 30.16. Monitoring with SONAR.

Monitoring DFS Using the System Monitor

Monitoring for DFS does not provide as many options as FRS. To monitor DFS, make sure the Process Performance object is selected; then select the dfssvr counter in the Select Instances list box. Some counters include total processor time, virtual bytes, private bytes, and page faults.

Taking a Target Offline for Maintenance

When a target needs to be rebooted or just taken offline for a short maintenance window, the connected users must be gracefully referred to another replica, or they must be disconnected from the DFS server.

To take a server offline for maintenance, follow these steps:

1.
Open the DFS console and locate the root you want.

2.
Select the DFS root or link that contains the target on the server you will be taking down for maintenance.

3.
Right-click the appropriate target and select Enable or Disable Referrals, as shown in Figure 30.17. This option changes the current referral status of a target.

Figure 30.17. Disabling DFS referral to free a server for maintenance.

[View full size image]

4.
Repeat the preceding steps for any additional DFS root or link targets on the server on which you are disabling referrals.

5.
Wait long enough for all the existing connections to close. Usually, after you make the referral change, all users should be disconnected after the cache interval has been exceeded. Start counting after the referral is disabled.

6.
When all users are off the server, perform the necessary tasks and enable referrals from the DFS console when maintenance is completed and server functionality has been restored.

Disabling Replication for Extended Downtime

When a server containing a replicated target folder will be offline for an extended period of timefor upgrades or because of unexpected network downtimeremoving that server's targets from replica sets is recommended, especially when a lot of replication data is transferred each day. Doing this relieves the available replica servers from having to build and store change orders and staging files for this offline server. Because the staging folder has a capacity limit, an offline server may cause the active server's staging folders to reach their limit, essentially shutting down all replication. When a staging folder reaches its limit, new change orders and staging files are not created until existing change orders are processed. Even though a replica server is offline, available replicas containing outbound connections to this server are still populating their staging folders with data to send to this server. If replica data changes frequently, the staging folders may fill up inadvertently, halting all replication on servers with outbound connections to the offline server. To avoid this problem, removing the replica from the set is the easiest method.

When the server is once again available, the administrator can add this server back to the list of targets and configure replication. The data will be moved to the pre-existing folder where it can be compared to file IDs sent over on the change orders from the initial master. If the file ID is the same, it will be pulled from the pre-existing folder instead of across the WAN.

The Enable button can be deselected on a replication connection, but this is not desired for maintenance because this server will not get the correct data change orders after replication is enabled.

Event Logging for FRS

When the File Replication Service is enabled on a server such as a Windows Server 2003 domain controller or a server hosting a replicated DFS target, event logging is enabled. Using the Event Viewer console, administrators can review the history and status of the File Replication Service by reading through the events in the FRS event log.


Backing Up DFS

Currently, there is no separate backup tool or strategy for backing up in DFS. The following elements should be backed up:

  • Target data This is the actual data that is being accessed by end users. With a true multi-master replication topology, only one target needs to be backed up.

  • DFS hierarchy For standalone DFS, the system state of the root server and system state of all servers containing DFS targets should be backed up. For domain-based DFS, the system states of domain controllers and all other servers containing DFS targets should be backed up. Active Directory stores all the DFS hierarchy and FRS replication connection information. Active Directory is backed up with the domain controller system state.

Using the DFScmd.exe Utility

DFScmd.exe is a command-line administrative utility for DFS. Using this tool, administrators can create roots and links and define replication between targets. This tool can be used to perform a quick backup of the DFS hierarchy of any particular DFS roots.

To perform a backup of a current domain root named Apps, for example, you can run this command and then press Enter:

DFScmd.exe /View \\domain\Apps /Batch /Batchrestore > DFSrestore.bat

This file can be run to re-create a lost or deleted link and targets. This tool cannot recreate the DFS root or replication, but after the root has been manually re-created, the rest of the DFS tree hierarchy can be restored by running the batch file created using DFScmd.exe and a console redirection to a batch file. Replication needs to be configured using the DFS console.

For more detailed information on the uses of DFScmd.exe, you can access the built-in help commands at the command prompt by typing DFScmd.exe /? and pressing Enter.


Handling Remote Storage

Remote Storage is a Windows Server 2003 file system service that is used to automatically archive data to removable media from a managed NTFS volume. Files are migrated by Remote Storage when they haven't been accessed for an extended period of time or when a managed disk drops below a certain percent of free disk space. When Remote Storage migrates to a file or folder, it is replaced on the volume with a file link called a junction point. Junction points take up very little room, which reduces the amount of used disk space but leaves a way for this data to be accessed later in the original location. When a junction point is accessed, it spawns the Remote Storage service to retrieve the file that was migrated to tape.

Remote Storage Best Practices

On volumes managed by Remote Storage, antivirus software should be limited to scanning files only upon access. If the antivirus software scans the volume on a regular schedule, all the data previously migrated by Remote Storage may be requested and need to be migrated back to disk. Also, Windows Server 2003compatible backup programs have options to allow the backup to follow junction points and back up data stored on Remote Storage. This may seem like a great feature, but it can cause several requests to be sent to the backup devices for data that is stored across several disks. This can extend a nightly backup window for many hours more than expected, and the performance of the Remote Storage server may be severely impacted during this operation.

Also, if a volume contains a DFS target configured for replication, Remote Storage should not be enabled on that volume. If a new target is added to a replicating DFS link, the entire contents of that DFS target folder will be read by the File Replication Service. This read operation is necessary to generate the staging files in preparation of synchronizing the target data. This operation causes all the migrated files to be restored back to the volume.

Installing Remote Storage

Installing the Remote Storage service takes only a few minutes and requires the Windows Server 2003 installation media. To install and configure Remote Storage, follow these steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Ensure that a Windows Server 2003 remote storagecompatible tape or optical media device or library has been installed and configured on the desired server. Review the Windows Server 2003 Hardware Compatibility List on the Microsoft Web site to verify that the device works with the Remote Storage service.
3. | Click Start, Control Panel, Add or Remove Programs.
4. | Select Add/Remove Windows Components from the left pane.
5. | Scroll down the list, check the box next to Remote Storage, and click Next to begin installation.
6. | If the Windows Server 2003 media are not located, you will be prompted to locate the media. Perform this step when necessary.
7. | Click Finish on the Completing the Windows Components Wizard and click Yes to restart the computer.

Configuring Remote Storage

One of the real beauties of Remote Storage is that there are very few options to configure, making implementation almost a snap. Configuring Remote Storage consists of only a few primary tasks:

  • Configure the backup device that Remote Storage will use.

  • Designate and manage the removable media that Remote Storage will use.

  • Configure the settings for Remote Storage on the managed volumes.

Configuring the Backup Device

Remote Storage requires a backup device to migrate the data from the managed volume. If third-party backup software will be installed on a server running Remote Storage, it is recommended to install at least two separate backup devices and enable the Removable Storage service to access only one. This will prevent any conflicts with backup devices when both Remote Storage and the backup software want to simultaneously access the device. If only one backup device is available, try to avoid third-party backup products, unless it is certain that conflicts will not be encountered. Third-party backup agents running backups to remote servers and backup devices do not affect Remote Storage and local backup devices. All backup devices, such as tape drives, robotic tape libraries, and CD-ROMs are enabled by default to be managed by the Removable Storage service. Because Remote Storage uses this service to access the backup devices, a backup device for Remote Storage is configured by enabling the device to the Removable Storage service.

To enable a device, follow these steps:

1.
Install the backup device or library on the Windows Server 2003 system. Use the backup device manufacturer's documentation to accomplish this process.

2.
After the backup device is connected, boot up the server and log on using an account with Local Administrator access.

3.
Click Start, All Programs, Administrative Tools, Computer Management.

4.
In the left pane, if it is not already expanded, double-click Computer Management (local).

5.
Click the plus sign next to Storage.

6.
Click the plus sign next to Removable Storage.

7.
Click the plus sign next to Libraries.

8.
Right-click the library (backup device) you want and select Properties.

9.
On the General tab of the Device Properties page, check the Enable Drive box, as shown in Figure 30.18, and click OK. To prevent the Removable Storage service from using this device, uncheck this box and click OK.

Figure 30.18. Enabling a backup device for the Removable Storage service.

Note

In Figure 30.18, the backup device selected is a single DLT tape device. Remote Storage can work with a single-tape device, but using it with robotic tape libraries that can change a tape is recommended to locate and restore data that is stored on multiple pieces of media automatically. A single-tape device requires administrator intervention when a file migrated by Remote Storage needs to be restored.

Allocating Removable Media for Remote Storage

After a device is configured for Remote Storage, you must allocate media for Remote Storage to use. When new or blank media are inserted in a device, upon device inventory, this media will be placed in the free media pool. If media were previously used by a different server or backup software, they are placed in the import, unrecognized, or backup media pools upon device inventory. The backup media pool is for media used by the local server's Windows Server 2003 Backup application.

To inventory a backup device and allocate media for remote storage, follow these steps:

1.
Locate the desired device, as outlined in the preceding section. Then right-click the device and choose Inventory.

2.
After the device completes the inventory process, select the backup device in the left pane. The media will then be listed in the right pane.

3.
Right-click the media listed in the right pane and select Properties.

4.
On the Media tab of the Media Properties page, note the media pool membership in the Location section. Figure 30.19 shows media that are part of the Import\DLT media pool.

Figure 30.19. Removable media in the Import\DLT media pool.

5.
Click Cancel to close the Media Properties page.

If the media are not in the free or remote storage media pool, they must be placed there before Remote Storage can use them. The Remote Storage service uses the remote storage media pool for locating and storing media for file migration or archival purposes. The remote storage media pool is configured by default to look for media in the free pool if media in the backup device are not already in the remote storage media pool.

If the media are not in the free or remote storage media pool and can be overwritten, right-click the media and select Free. A warning message pops up stating that this media will be moved to the free pool and any data currently on the media will be lost. If that is okay, click Yes; otherwise, click No, insert a different piece of media into the backup device, and restart the backup process.

Configuring a Volume for Remote Storage Management

When the backup devices and removable media have been configured properly, a volume for remote storage management can be configured. To configure a managed volume, follow these steps:

1.
Log on to the desired Remote Storage server using an account with Local Administrator access.

2.
Click Start, All Programs, Administrative Tools, Remote Storage.

3.
If this is the first time the Remote Storage console has been opened or no volumes on the server have been configured for remote storage management, the Remote Storage Wizard will begin. Click Next on the Welcome screen to continue.

4.
On the Volume Management page, choose whether to manage all volumes or manage only selected volumes by selecting the correct radio button. If you selected Manage All Volumes, click Next.

5.
If you chose Manage Selected Volumes, check the volume you want to manage and click Next.

6.
On the Volume Settings page, enter the amount of free space you want for the managed volume.

7.
On the same page, configure the minimum file size before it will be migrated by Remote Storage; then configure the number of days a file must remain unaccessed before Remote Storage will make it a possible candidate for migration. Then click Next. Figure 30.20 shows a volume setting that will migrate data to Remote Storage when a volume has 10% free space remaining, and the file that will be migrated must be larger than 12KB and must remain unaccessed for 120 days.

Figure 30.20. Setting typical Remote Storage volume settings.

8.
On the Media Type page, choose the media type associated with the backup device enabled for Remote Storage to use. Choose a media type from the Media Types pulldown menu.

9.
On the next page, you can configure a schedule to perform the file copy. The default is to run at 2 a.m. seven days a week. Click the Change Schedule button to configure a custom schedule or click Next to accept the default schedule.

10.
Click Finish on the Completing the Remote Storage Wizard page to complete the process.

When the process is complete, the Remote Storage console opens. This console can be used to manually initiate Remote Storage tasks on managed volumes, such as starting a file copy based on last file access time, to validate files or to create free space if the drive is below the free space threshold. This console can also be used to manage removable media. For more information on Remote Storage, refer to Chapter 32, "Backing Up a Windows Server 2003 Environment," and Chapter 33, "Recovering from a Disaster."


Using the Volume Shadow Copy Service

The Windows Server 2003 Volume Shadow Copy service (VSS) is a new feature available for volumes using NTFS. VSS is used to perform a point-in-time backup of an entire volume to the local disk. This backup can be used to quickly restore data that was deleted from the volume locally or through a network mapped drive or network file share. VSS is also used by the Windows Server 2003 Backup program to back up local and shared NTFS volumes. If the volume is not NTFS, Volume Shadow Copy will not work.

VSS can make a point-in-time backup of a volume, including backing up open files. This entire process is completed in a very short period of time but is powerful enough to be used to restore an entire volume, if necessary. VSS can be scheduled to automatically back up a volume once, twice, or several times a day. This service can be enabled on a volume that contains DFS targets and standard Windows Server 2003 file shares.

Using VSS and Windows Server 2003 Backup

When the Windows Server 2003 Backup program runs a backup of a local NTFS volume, VSS is used by default to create a snapshot or shadow copy of the volume's current data. This data is saved to the same or another local volume or disk. The Backup program then uses the shadow copy to back up data, leaving the disk free to support users and the operating system. When the backup is complete, the shadow copy is automatically deleted from the local disk. For more information on VSS and Windows Server 2003 Backup, refer to Chapters 32 and 33.

Configuring Shadow Copies

Enabling shadow copies for a volume can be very simple. Administrators have more options when it comes to recovering lost or deleted data and, in many cases, can entirely avoid restoring data to disk from a backup tape device or tape library. In addition, select users can be given the necessary rights to restore files that they've accidentally deleted.

From a performance standpoint, it is best to configure shadow copies on separate disks or fast, hardware-based RAID volumes (for example, RAID 1+0). This way, each disk performs either a read or write operation for the most part, not both. Volume Shadow Copy is already installed and is automatically available using NTFS-formatted volumes.

To enable and configure shadow copies, follow these steps:

1.
Log on to the desired server using an account with Local Administrator access.

2.
Click Start, All Programs, Administrative Tools, Computer Management.

3.
In the left pane, if it is not already expanded, double-click Computer Management (Local).

4.
Click the plus sign next to Storage.

5.
Select Disk Management.

6.
Right-click Disk Management, select All Tasks, and select Configure Shadow Copies.

7.
On the Shadow Copies page, select a single volume for which you want to enable shadow copies and click Settings.

8.
The Settings page allows you to choose an alternate volume to store the shadow copies. Select the desired volume for the shadow copy, as shown in Figure 30.21.

Figure 30.21. Selecting an alternate drive to store the shadow copies.

9.
Configure the maximum amount of disk space that will be allocated to shadow copies.

10.
The default schedule for shadow copies is twice a day at 7 a.m. and 12 p.m. If this does not meet your business requirements, click the Schedule button and configure a custom schedule.

11.
Click OK to enable shadow copies on that volume and to return to the Shadow Copies page.

12.
If necessary, select the next volume and enable shadow copying; otherwise, select the enabled volume and immediately create a shadow copy by clicking the Create Now button.

13.
If necessary, select the next volume and immediately create a shadow copy by clicking the Create Now button.

14.
After the shadow copies are created, click OK to close the Shadow Copies page, close the Computer Management console, and log off the server.

For more detailed information concerning the Volume Shadow Copy service, refer to Chapters 32 and 33.

Recovering Data Using Shadow Copies

The server administrator or a standard user who has been granted permissions can recover data using previously created shadow copies. The files stored in the shadow copy cannot be accessed directly, but they can be accessed by connecting the volume that has had a shadow copy created.

Note

The Shadow Copies for Shared Folders Restore Tool (VolRest), located in the Windows Server 2003 Resource Kit, is a command-line tool that can be used to restore previous file versions. The Shadow Copies for Shared Folders feature must be enabled to use this tool to restore previous versions of files.

To recover data from a file share, follow these steps:

1.
Log on to a Windows Server 2003 system or Windows XP SP1 workstation with either Administrator rights or with a user account that has permissions to restore the files from the shadow copy.

2.
Click Start, Run.

3.
At the Run prompt, type \\servername\sharename, where servername represents the NetBIOS or fully qualified domain name of the server hosting the file share. The share must exist on a volume in which a shadow copy has already been created.

4.
In the File and Folder Tasks window, select View Previous Versions, as shown in Figure 30.22.

Figure 30.22. Using shadow copies to view previous file versions.

5.
When the window opens to the Previous Versions property page for the share, select the shadow copy from which you want to restore and click View.

6.
An Explorer window then opens, displaying the contents of the share when the shadow copy was made. If you want to restore only a single file, locate the file, right-click it, and select Copy.

7.
Close the Explorer window.

8.
Close the Share Property pages by clicking OK at the bottom of the window.

9.
Back in the actual file share window, browse to the original location of the file, right-click on a blank spot in the window, and select Paste.

10.
Close the file share window.

Managing Shadow Copies

Volume shadow copies do not require heavy management, but if shadow copies are on a schedule, the old copies need to be manually removed. You can use the Shadow Copies windows available through Disk Manager or automate this task by using a batch script and the utility Vssadmin.exe.

To delete a shadow copy using Disk Manager, follow these steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Click Start, All Programs, Administrative Tools, Computer Management.
3. | In the left pane, if it is not already expanded, double-click Computer Management (Local).
4. | Click the plus sign next to Storage.
5. | Select Disk Management.
6. | Right-click Disk Management, select All Tasks, and click Configure Shadow Copies.
7. | Select the desired volume in the Select a Volume section.
8. | In the Shadow Copies of Selected Volume section, select the shadow copy you want to delete and click the Delete Now button.
9. | Click OK to close the Shadow Copies window, close the Computer Management console, and log off the server.

To delete the oldest shadow copy from the D: volume, at a command prompt, type the following command and then press Enter:

Vssadmin.exe Delete Shadows /For=D: /Oldest

Vssadmin.exe can be used to create, delete, and manage shadow copies. For more information on this tool, refer to Chapter 32.

Note

The Windows Server 2003 Resource Kit contains performance counters (Volperf) for VSS and can be used in conjunction with the System Monitor to monitor shadow copies.


Summary

Windows Server 2003 file services give administrators several options when it comes to building fault-tolerant servers and data storage as well as fault-tolerant file shares. Through services such as Windows File Protection and Volume Shadow Copy, deleted or overwritten files can be restored automatically or by an administrator without restoring from backup. Using services such as the Distributed File System and the File Replication Service, administrators have more flexibility when it comes to deploying, securing, and providing high-availability file services. Using just one or a combination of these file system services, organizations can truly make their file systems fault tolerant.


Best Practices

  • Use the Volume Shadow Copy service to provide file recoverability and data fault tolerance to minimize the number of times you have to restore from backup.

  • Use Remote Storage to migrate data from a disk volume to remote storage media based on when a file was last accessed or when a managed disk reaches a predetermined free disk space threshold.

  • Do not configure Remote Storage to manage volumes that contain FRS replicas because doing so can cause unnecessary data migration.

  • Try to provide disk fault tolerance for your operating system and data drives, preferably using hardware-based RAID sets.

  • Completely format RAID 5 volumes to avoid loss of disk performance later when data is being first copied to the volumes.

  • Use NTFS whenever possible on all volumes.

  • Convert basic disks to dynamic disks.

  • Always define share permissions for every share regardless of the volume format type.

  • Replace the Everyone group with the Domain Users group when shares are created on domain servers and anonymous or guest access is not required, and set the share permissions accordingly.

  • Do not enable client-side caching on the file share if roaming user profiles are used on a network because this may cause corruption to the end user's profile.

  • Use File Server Resource Manager (FSRM) quotas as part of the Windows 2003 R2 update, instead of NTFS quotas, for better quota management capabilities.

  • Monitor disk performance using utilities such as System Monitor and fsutil.

  • Audit file and folder security.

  • Require that only certified hardware drivers be installed on the system.

  • Install and use DFS that comes with the Windows 2003 R2 update to get better DFS operation and replication functionality.

  • Use domain-based DFS roots whenever possible.

  • Use DFS to provide a unified namespace to file data.

  • Use NTFS volumes for DFS root and link target file shares to enable file- and folder-level security. Also, domain DFS links can be replicated only between file shares on NTFS volumes.

  • Start with an empty DFS root folder to keep from having to replicate any data at the root level.

  • Do not replicate DFS roots because the root will try to replicate the data in the root folders plus the data contained within the link targets. Replication is not necessary if the links are already replicating. Because the roots do not replicate for redundancy, deploy domain DFS roots and add additional root targets.

  • Use DFS for read-only data, if possible.

  • Replicate DFS data only during nonpeak hours to reduce network congestion.

  • Back up at least one DFS link target and configure the backup to not update the archive bit. Changing the archive bit may trigger unnecessary replication.

  • Test antivirus programs thoroughly to ensure that no adverse effects are caused by the scanning of files on a replicated DFS target.

  • Verify that the drive containing the staging folder for a replication connection contains ample space to accept the amount of replicated data inbound and outbound to this server.


Chapter 31. System-Level Fault Tolerance (Clustering/Network Load Balancing)

In This Chapter

  • Building Fault-Tolerant Systems

  • Examining Windows Server 2003 Clustering Technologies

  • Choosing the Right Clustering Technology

  • Implementing Cluster Service

  • Installing Cluster Service

  • Managing Clusters

  • Backing Up and Restoring Clusters

  • Upgrading Cluster Nodes

  • Installing Network Load Balancing Clusters

  • Managing NLB Clusters

In many of today's business environments, using computer applications and networking services has become critical in conducting day-to-day business functions efficiently. The word downtime has become taboo in situations in which an unstable application or a failed server can greatly impact employee productivity or cost organizations money. Deploying fault-tolerant servers to provide reliable access to critical applications, user data, and networking services is required when unexpected downtime is unacceptable.

Windows Server 2003 provides several methods of improving system- or server-level fault tolerance by using a few of the services included in the Enterprise and Datacenter platforms. Chapter 30, "File System Fault Tolerance," discussed file-level fault tolerance, including the Distributed File System (DFS) and volume shadow copies. This chapter covers system-level fault tolerance using Windows Server 2003 network load balancing (NLB) and the Microsoft Cluster Service (MSCS). These built-in clustering technologies provide load-balancing and failover capabilities that can be used to increase fault tolerance for many different types of applications and network services. Each of these clustering technologies is different in many ways. Choosing the correct type of clustering depends on the applications and services that will be hosted on the cluster.

Windows Server 2003 technologies such as NLB and MSCS improve fault tolerance for applications and network services, but before these technologies can be leveraged effectively, basic server stability best practices must be put in place.

This chapter focuses on the policies and procedures needed to create an environment that supports a fault-tolerant network. Additionally, this chapter contains the step-by-step procedures needed to make server hardware more reliable through the successful implementation of NLB and MSCS.


Building Fault-Tolerant Systems

Building fault-tolerant computing systems consists of carefully planning and configuring server hardware and software, network devices, and power sources. Purchasing quality server and network hardware is a good start to building a fault-tolerant system, but the proper configuration of this hardware is equally important. Also, providing this equipment with stable line power that is backed up by a battery or generator adds fault tolerance to the network. Last but not least, proper tuning of server operating systems helps enhance availability of network services such as file shares, print servers, network applications, and authentication servers.

Using Uninterruptible Power Supplies

Connecting line power to server and network devices through uninterruptible power supplies (UPSs) not only provides conditioned incoming power by removing voltage spikes and providing steady line voltage levels, but it also provides battery backup power. When line power fails, the UPS switches to battery mode, which should provide ample time to shut down the server or network device without risk of damaging hardware or corrupting data. UPS manufacturers commonly provide software that can send network notifications, run scripts, or even gracefully shut down servers when power thresholds are met. One final word on power is that most computer and network hardware manufacturers provide device configurations that incorporate redundant power supplies designed to keep the system powered up in the event of a single power supply failure.

During power outages, many system administrators find out which critical devices are not connected to a UPS, and the race begins to shut down and shift power from non-critical devices. To avoid these situations, administrators need to perform regular inspections of critical hardware devices in server rooms and network closets to ensure that all necessary servers, network routers, switches, hubs, and firewalls are backed by battery power. When power to a server fails and the battery provides only a few minutes for users to save data and close connections to reduce the chance of data corruption, it is essential for the network to remain available.

Choosing Networking Hardware for Fault Tolerance

Network design can also incorporate fault tolerance by creating redundant network routes and by utilizing technologies that can group devices together for the purposes of load balancing and device failover. Load balancing is the process of spreading requests across multiple devices to keep individual device load at an acceptable level. Failover is the process of moving services offered on one device to another upon device failure, to maintain availability.

Networking hardware such as Ethernet switches, routers, and network cards can be configured to provide fault-tolerant services through load-balancing applications or through features within the network device firmware or operating system. Refer to the manufacturer's documentation to research fault-tolerant configurations available in your organization's network devices.

For more robust redundant network card configurations, third-party hardware vendors have created network card teaming and network card fault-tolerant software applications. These technologies allow client/server communication to fail over from one network interface card (NIC) to another in the event of an NIC failure. Also, they can be configured to balance network requests across all the NICs in one server simultaneously. Refer to the particular hardware manufacturer's documentation to find out whether a compatible teaming application is available for your network card.

Note

Windows Server 2003 network load balancing does not allow multiple NICs on the same server to participate in the same NLB cluster.

Selecting Server Storage for Redundancy

Server disk storage usually contains user data and/or operating system files that make it a critical server subsystem that should incorporate fault tolerance. There are a few different ways to create fault-tolerant disk storage for the Windows Server 2003 operating system. The first is creating Redundant Arrays of Inexpensive Disks (RAID) using disk controller configuration utilities, and the second is creating the RAID disks using dynamic disk configuration from within the Windows Server 2003 operating system.

Using two or more disks, different RAID-level arrays can be configured to provide fault tolerance that can withstand disk failures and still provide uninterrupted disk access. Implementing hardware-level RAID configured and stored on the disk controller is preferred over the software-level RAID configurable within Windows Server 2003 Disk Management because the Disk Management and synchronization processes in hardware-level RAID are offloaded to the RAID controller. With Disk Management and synchronization processes offloaded from the RAID controller, the operating system will perform better overall.

Another good reason to provide hardware-level RAID is that the configuration of the disks does not depend on the operating system, which gives administrators greater flexibility when it comes to recovering server systems and performing upgrades. Refer to Chapter 22, "Windows Server 2003 Management and Maintenance Practices," for more information on ways to create RAID arrays using Windows Server 2003 Disk Management. Also, refer to the manufacturer's documentation on creating RAID arrays on your RAID disk controller.

Improving Application Reliability

An application's reliability is greatly dependent on the software code and the hardware it is running on. Administrators can make applications more reliable on Windows Server 2003 by running legacy client/server applications in lower application compatibility modes to improve overall reliability; they do so by isolating each application instance to a separate memory location. If one instance crashes, the remaining instances and the server itself remain available and unaffected. Reliability for client/server-based applications written for Windows Server 2003 can be improved by deploying these applications on clusters. Windows Server 2003 Enterprise and Datacenter servers provide two different clustering technologies that enhance application reliability by providing server load balancing and failover capabilities.


Examining Windows Server 2003 Clustering Technologies

Windows Server 2003 provides two clustering technologies, which are included on the Enterprise and Datacenter server platforms. Clustering is the grouping of independent server nodes that are accessed and viewed on the network as a single system. When an application is run from a cluster, the end user can connect to a single cluster node to perform his work, or each request can be handled by multiple nodes in the cluster. In cases where data is read-only, the client may request data and receive the information from all the nodes in the cluster, improving overall performance and response time.

The first clustering technology Windows Server 2003 provides is Cluster Service, also known as Microsoft Cluster Service (MSCS). The Cluster Service provides system fault tolerance through a process called failover. When a system fails or is unable to respond to client requests, the clustered services are taken offline and moved from the failed server to another available server, where they are brought online and begin responding to existing and new connections and requests. Cluster Service is best used to provide fault tolerance for file, print, enterprise messaging, and database servers.

The second Windows Server 2003 clustering technology is network load balancing (NLB) and is best suited to provide fault tolerance for front-end Web applications and Web sites, Terminal servers, VPN servers, and streaming media servers. NLB provides fault tolerance by having each server in the cluster individually run the network services or applications, removing any single points of failure. Certain applicationsfor example, Terminal Servicesrequire a client to connect to the same server during the entire session, while clients viewing Web sites can request pages from any node in the cluster during a visit. Configuring how client/server communication is divided and balanced across the servers is dependent on the application's needs.

Note

Microsoft does not support running both MSCS and NLB on the same computer due to potential hardware sharing conflicts between the two technologies.

Reviewing Cluster Terminology

Before you can design and implement MSCS and NLB clusters, you must understand certain clustering terminology. The following list describes key terms associated with Windows Server 2003 clustering:

  • Cluster A cluster is a group of independent servers that are accessed and viewed on the network as a single system.

  • Node A node is an independent server that is a member of a cluster.

  • Cluster resource A cluster resource is a network application or service defined and managed by the cluster application. Some examples of cluster resources are network names, IP addresses, logical disks, and file shares.

  • Cluster resource group Cluster resources are contained within a cluster in a logical set called a cluster resource group, or commonly referred to as a cluster group. Cluster groups are the units of failover within the cluster. When a cluster resource fails and cannot be restarted automatically, the entire cluster group is taken offline and failed over to another available cluster node.

  • Cluster virtual server A cluster virtual server is a cluster resource group that contains a network name and IP address resource. Virtual server resources are accessed either by the domain name system (DNS) or NetBIOS name resolution or directly from the IP address. The name and IP address remain the same regardless of which cluster node the virtual server is running on.

  • Cluster heartbeat The cluster heartbeat is the communication that is kept between individual cluster nodes that is used to determine node status. Typically, heartbeat communication between nodes must be no longer than 500 milliseconds, or the nodes may believe that there is a failure and commence cluster group failovers.

  • Cluster quorum disk The cluster quorum disk maintains the definitive cluster configuration data. MSCS uses a quorum disk or disks and requires continuous access to the cluster configuration data contained within it. The quorum contains configuration data defining which server nodes actively participate in the cluster, what applications and services are defined in the cluster, and the current states of the resources and the individual nodes. This data is used to determine whether a particular resource group or groups need to be failed to an available cluster node in the event of a failure on an active node. If a cluster node loses access to the quorum, the Cluster Service will fail on that node. In a typical MSCS cluster, the quorum resource is located on a shared storage device.

  • Local quorum resource Like the quorum resource, the local quorum contains the cluster configuration data. Unlike the standard quorum device that is usually housed on a shared disk, the local quorum is kept on a node's local disk. The local quorum resource was created for single-node cluster configurations, commonly used for cluster application development and testing.

  • Majority Node Set (MNS) resource The MNS resource is the quorum resource used for a Majority Node Set cluster. The MNS resource maintains consistent configuration data across all the nodes in the cluster. If the MNS quorum is lost, it can be recovered by "forcing the quorum" on a remaining cluster node. Refer to the Windows Server 2003 online help and look for the topic "Forcing the Quorum in a Majority Node Set Cluster."

  • Generic cluster resource Generic cluster resources were created to define cluster-unaware applications within a cluster group. This gives the ability to fail the resource over to another node in the cluster when the active node fails. This resource is not monitored by the cluster application; therefore, application failure does not result in a restart or failover scenario. Generic cluster resources include the generic application, generic script, and generic service resources. For more information on these resources, refer to the Windows Server 2003 Help and Support tool and search for "generic cluster resources."

  • Cluster-aware application A cluster-aware application provides a mechanism by which the Cluster Service can test the application availability to determine whether it is functioning as desired. When a cluster-aware application fails, the cluster can stop and restart the application as necessary on the same node and, if necessary, move it to another available node where it can be restarted.

  • Cluster-unaware application A cluster-unaware application can run on a cluster, but the application itself is not monitored by the Cluster Service. This means that the cluster can fail over the application only in the event that another resource fails in the cluster group. If the application stops responding, the cluster is not aware and therefore cannot restart it. Keep in mind that there are other ways to manage cluster-unaware applications outside the cluster, and in some cases these approaches may be the only option. For more information on how to install and configure generic applications, refer to the Windows Server 2003 Help and Support and search for "generic application resource type."

  • Failover Failover is the process of a cluster group moving from the current active node to another available node in the cluster. Failover occurs when a server becomes unavailable or when a resource in the cluster group fails and cannot recover with the failure threshold.

  • Failback Failback is the process of a cluster group moving back to a preferred node after the preferred node resumes cluster membership. Failback must be configured within a cluster group for this to happen. The cluster group must have a preferred node defined and a failback threshold configured. A preferred node is the node you would like your cluster group to run on during regular cluster operation. When a group is failing back, the cluster is performing the same failover operation but is triggered by a server rejoining or resuming cluster operation instead of by a server or resource failure.

Note

Plan carefully when considering failback. For more information, refer to the "Configuring Failover and Failback" section later in this chapter.

Active/Passive Clustering Mode

Active/passive clustering occurs when one node in the cluster provides clustered services while the other available node or nodes remain online but do not provide services or applications to end users. When the active node fails, the cluster groups previously running on that node are failed over to the passive node, causing the node's participation in the cluster to go from passive to active state to begin servicing client requests.

This configuration is usually implemented with database servers that provide access to data that is stored in only one location and is too large to replicate throughout the day. One advantage of Active/Passive mode is that if each node in the cluster has similar hardware specifications, there is no performance loss when a failover occurs. The only real disadvantage of this mode is that the passive node's hardware resources cannot be leveraged during regular daily cluster operation.

Note

Active/passive configurations are a great choice for keeping cluster administration and maintenance as low as possible. For example, the passive node can be used to test updates and other patches without directly impacting production. However, it is nonetheless important to test in an isolated lab environment or, at a minimum, during after hours or predefined maintenance windows.

Active/Active Clustering Mode

Active/active clustering occurs when one instance of an application runs on each node of the cluster. When a failure occurs, two or more instances of the application can run on one cluster node. The advantage of Active/Active mode over Active/Passive mode is that the physical hardware resources on each node are used simultaneously. The major disadvantage of this configuration is that if you are running each node of the cluster at 100% capacity, in the event of a node failure, the remaining active node assumes 100% of the failed node's load, greatly reducing performance. As a result, it is critical to monitor server resources at all times and ensure that each node has enough resources to take over the other node's responsibilities if the other should failover.


Choosing the Right Clustering Technology

For these fault-tolerant clustering technologies to be most effective, administrators must carefully choose which technology and configuration best fits their application or network service needs. NLB is best suited to provide connectivity to TCP/IP-based services such as Terminal Services, Web sites, VPN services, and streaming media services. This provides scalability, and the amount of redundancy it provides depends on the number of systems in the NLB set. The Windows Server 2003 Cluster Service provides server failover functionality for mission-critical applications such as enterprise messaging, databases, and file and print services.

Although Microsoft does not support using both NLB and MSCS on the same server, multi-tiered applications can take advantage of both technologies by using NLB to load-balance front-end application servers and using MSCS to provide failover capabilities to back-end databases that contain data too large to replicate during the day.

Microsoft Cluster Service

Microsoft Cluster Service (MSCS) is a clustering technology that provides system-level fault tolerance by using a process called failover. Cluster Service is used best to provide access to resources such as file shares, print queues, email or database services, and back-end applications. Applications and network services defined and managed by the cluster, along with cluster hardware including shared disk storage and network cards, are called cluster resources. Cluster Service monitors these resources to ensure proper operation.

When a problem is encountered with a cluster resource, Cluster Service attempts to fix the problem before failing it completely. The cluster node running the failing resource attempts to restart the resource on the same node first. If the resource cannot be restarted, the cluster will fail the resource, take the cluster group offline, and move it to another available node, where it can then be restarted.

Several conditions can cause a cluster group to fail over. Failover can occur when an active node in the cluster loses power or network connectivity or suffers a hardware failure. Also, when a cluster resource cannot remain available on an active node, the resource's group is moved to an available node, where it can be started. In most cases, the failover process is either noticed by the clients as a short disruption of service or no disruption at all.

To avoid unwanted failover, power management should be disabled on each of the cluster nodes in the motherboard BIOS, on the network interface cards, and in the Power applet in the operating system's Control Panel. Power settings that allow a monitor to shut off are okay, but the administrator must make sure that the disks are configured to never go into standby mode.

Cluster nodes can monitor the status of resources running on their local system, and they can also keep track of other nodes in the cluster through private network communication messages called heartbeats. The heartbeats are used to determine the status of a node and send updates of cluster configuration changes to the cluster quorum resource.

The quorum resource contains the cluster configuration data necessary to restore a cluster to a working state. Each node in the cluster needs to have access to the quorum resource; otherwise, it will not be able to participate in the cluster. Windows Server 2003 provides three types of quorum resources, one for each cluster configuration model.

Using Network Load Balancing

The second clustering technology provided with the Windows Server 2003 Enterprise and Datacenter server platforms is network load balancing. NLB clusters provide high network performance and availability by balancing client requests across several servers. When client load increases, NLB clusters can easily be scaled out by adding more nodes to the cluster to maintain or provide better response time to client requests.

Two great features of network load balancing are that no proprietary hardware is needed, and an NLB cluster can be configured and up and running literally in minutes. NLB clusters can grow to 32 nodes, and if larger cluster farms are necessary, DNS round robin or a third-party solution should be investigated to meet this larger demand.

One important point to remember is that within NLB clusters, each server's configuration must be updated independently. The NLB administrator is responsible for making sure that application configuration and data are kept consistent across each node. Applications such as Microsoft's Application Center can be used to manage content and configuration data among those servers participating in the NLB cluster. To install network load balancing, proceed directly to the "Installing Network Load Balancing Clusters" section later in this chapter.


Implementing Cluster Service

After an organization decides to cluster an application or service using Cluster Service, it must then decide which cluster configuration model best suits its needs.

MSCS can be deployed in three different configuration models that will accommodate most deployment scenarios and requirements. The three configuration models include the single-quorum device cluster, single-node cluster, and the majority node set cluster. The typical and most common cluster deployments are configured using the single-quorum device cluster.

The Single-Quorum Device Cluster

The single-quorum device cluster configuration model is composed of two or more server nodes that are all connected to a shared storage device. In this model, only one copy of the quorum data is maintained and is housed on the shared storage device, as shown in Figure 31.1. All cluster nodes have access to the quorum data, but the quorum disk resource runs only on one node of the cluster at a time.

Figure 31.1. Two-node single-quorum device cluster.

This configuration model is best suited for applications and services that provide access to large amounts of mission-critical data and require high availability. When the cluster encounters a problem on a cluster group containing a shared storage disk resource, the cluster group is failed over to the next node and made available with almost no disruption. When the cluster group is back online, all the data is once again available after a short disruption in service. Typical services deployed using this cluster configuration model include file, messaging, and database servers.

The Single-Node Cluster

The single-node cluster configuration model was created to serve many purposes. First, a single-node cluster can run solely on local disks, but it can also use shared storage. When creating a single-quorum cluster, the administrator must first create a single-node cluster but with a shared disk quorum. The single-node cluster can also use the local quorum resource, which is usually located on internal disk storage. The local quorum resource is a great benefit for cluster application development because only a single server with internal disk storage is needed to test cluster applications.

One last point to add about this model is that because there is only one node, the cluster will not use or provide failover. If the single node is down, all the cluster groups are unavailable.

The Majority Node Set Cluster

The Majority Node Set (MNS) cluster is the third configuration model and represents the future of clustering, as shown in Figure 31.2. MNS can use shared storage devices, but this capability is not a requirement. In an MNS cluster, each node maintains a local copy of the quorum device data in a specific Majority Node Set resource. Windows Server 2003 Enterprise supports up to four nodes per cluster, and Datacenter supports up to eight nodes. Because each node maintains a local copy of the quorum and a shared storage device is not necessary, MNS clusters can be deployed across a WAN in a geographically distributed environment. Windows Server 2003 supports up to two separate sites for MNS, and because the cluster IP will need to fail over across sites, the sites either need to be bridged or a virtual private network (VPN). Another viable option is having Network Address Translation (NAT) installed and configured for failover for proper IP recovery to occur. The latency between the cluster nodes for private communication must not exceed 500 milliseconds; otherwise, the cluster can go into a failed state.

Figure 31.2. Two-site, four-node Majority Node Set cluster.

An MNS cluster will remain up and running as long as the majority of the nodes in the cluster are available. In other words, to remain operational, more than half of the nodes must be up and running. For instance, in a four-node cluster, three nodes must remain available, or the cluster will fail. If an administrator configures a three-node cluster, two nodes must remain up and running. Both the three-node and four-node clusters can tolerate only a single node failure.

If you are considering or requiring availability provided by MNS, it is recommended to always purchase at least one additional node when planning for an MNS cluster. This node can be used in the lab for application testing, including testing patches and application updates, or it can be configured in a cold-standby state that can be added to a cluster when a single node fails.

An MNS Cluster Scenario

An MNS cluster model supports geographically distributed clusters. This means that in a three-node cluster deployment, you can deploy two nodes in Site A and one node in Site B. A spare server will be kept at Site B to join the cluster if necessary. When a single node fails in Site A, the cluster remains up and running because the majority of the nodes are still running, even though they are running in separate sites. If the node in Site B fails, the cluster will remain running on the two nodes at Site A. If a major disaster or power outage is encountered at Site A, the cluster will fail because only one node is running at Site B. To bring the cluster back online, you can restore one of site A's nodes at the Site B location using the spare server. This gives you the two nodes you need to make the three-node MNS cluster operational.

In the same scenario, if you deploy a four-node cluster with two nodes at each site, a single site failure will result in the cluster failing and require an additional server to restore a third and required node. So, if you want to properly plan for a site outage using a four-node MNS cluster, you would need to have a spare server in each location, making the total six servers for a four-node cluster.

MNS is a great choice for geographically distributed clusters, but you must follow these rules to deploy the clusters properly:

  • The cluster nodes require less than a 500-millisecond response time between the private LAN adapters on each of the cluster nodes.

  • A VPN must be established between the sites to allow the clustered IP address to fail over across site boundaries while remaining accessible to clients. If the site's LANs are bridged across a WAN, this would also suffice. Also consider having redundant connections between those sites.

  • MNS can be deployed across only two sites.

  • Data other than the cluster quorum information does not automatically replicate between cluster nodes and needs to be replicated with software or replicated manually.

MNS clusters represent the future of clustering, and several developments will be made along the way to simplify installations and deployment. Microsoft recommends that MNS clusters be deployed only on hardware supported by the server and storage device vendors for use with geographically distributed MNS clusters.

Choosing Applications for Cluster Service

Many applications can run on Cluster Service, but it is important to choose those applications wisely. Although many can run on MSCS, the application might not be optimized for clustering. Work with the vendor to determine requirements, functionality, and limitations (if any). Other major criteria that should be met to ensure that an application can benefit and adapt to running on a cluster are the following:

  • Because clustering is IP-based, the cluster application or applications must use an IP-based protocol.

  • Applications that require access to local databases must have the option of configuring where the data can be stored.

    Some applications need to have access to data regardless of which cluster node they are running on. With these types of applications, it is recommended that the data is stored on a shared disk resource that will fail over with the cluster group. If an application will run and store data only on the local system or boot drive, the Majority Node Set cluster configuration, along with a separate file replication mechanism, should be considered.

  • Client sessions must be able to re-establish connectivity if the application encounters a network disruption.

    During the failover process, there is no client connectivity until an application is brought back online. If the client software does not try to reconnect and simply times out when a network connection is broken, this application may not be the best one to cluster.

Those cluster-aware applications meeting all the preceding criteria are usually the best applications to deploy in a cluster configuration. Many services built into Windows Server 2003 can be clustered and will fail over efficiently and properly. If a particular application is not cluster-aware, be sure to investigate all the implications of the application deployment on the Cluster server.

Note

If you're purchasing a third-party software package for MSCS, be sure that both Microsoft and the software manufacturer certify that it will work on a Windows Server 2003 cluster; otherwise, support will be limited when troubleshooting is necessary.

Shared Storage Devices

Shared disk storage was a requirement for all previous releases of MSCS until Windows Server 2003. Now only the traditional design of a single quorum device cluster has such a requirement, but a shared storage device can be a part of any cluster configuration.

In the past, storage area networks (SANs) were used to satisfy the shared storage device requirement. The logical volumes created in the SAN device must be configured and recognized as basic disks by the Windows Server 2003 operating system. Windows Server 2003 identifies the logical volumes on the SAN by their disk signatures, and each volume is treated as a separate disk by MSCS. Currently, dynamic disks are not supported for shared disk volumes. SCSI SAN units are supported on two-node clusters, but for clusters with more than two nodes, fiber channel is the preferred method of connecting cluster nodes to the shared storage.

Using a single fiber channel, Windows Server 2003 can access both shared and nonshared disks residing on a SAN. This allows both the shared storage and operating system volumes to be located on the SAN, giving administrators the flexibility of deploying diskless servers. Of course, the SAN must support this option, and the boot drives must be assigned exclusive access for individual cluster nodes through proper disk zoning and masking. Consult SAN vendor documentation and check the Cluster HCL on the Microsoft Web site to find approved SAN devices.

The Cluster server uses a shared nothing architecture, which means that each cluster resource can be running on only one node in the cluster at a time. When a disk resource is failed over between nodes, the SAN device must be reset to accommodate the mounting of the disk on the remaining node. If the SAN device is used by more than just cluster nodes, SAN communication can be disrupted to other servers if the SAN is not configured to reset only the targeted logical unit number (LUN) as opposed to resetting the entire bus. Windows Server 2003 supports targeted LUN resets, and SAN vendor documentation should be reviewed to ensure proper zoning and masking of the SAN device.

Multipath I/O

Windows Server 2003 supports multipath I/O to external storage devices such as SANs. This allows for multiple redundant paths to external storage, adding yet another level of fault tolerance. This capability is now achieved through redundant fiber channel controller cards in each cluster node.

Volume Shadow Copy for Shared Storage Volume

The Volume Shadow Copy (VSS) service is supported on shared storage volumes. Volume Shadow Copy can take a point-in-time snapshot of an entire volume, enabling administrators and users to recover data from a previous version. The amount of disk space used for each copy can be minimal, so enabling the service can add data fault tolerance and reduce recovery time of a file or folder. Volume Shadow Copy should be tested thoroughly on a disk containing enterprise databases such as Microsoft SQL 2000 prior to implementation to ensure that it can provide fault tolerance and recoverability as required and to ensure that databases do not suffer corruption as a result of a rollback to a previous version of the database file.

Single-Quorum Cluster Scalability

The single-quorum cluster is composed of independent server nodes that all connect to a share's storage device such as a SAN. Table 31.1 specifies the minimum and maximum number of nodes and types of storage communications allowed in a single-quorum cluster.

Table 31.1. Number of Nodes Allowed in a Cluster

Operating System

Number of Nodes

Allowed Cluster Storage Device

Windows Server 2003
Enterprise Server

2, 3, 4, 5, 6, 7, or 8

SCSI, fiber channel (recommended for clusters with more than two nodes)

Windows Server 2003
Datacenter Edition

2, 3, 4, 5, 6, 7, or 8

SCSI, fiber channel (recommended for clusters with more than two nodes)

64-bit edition of Windows
Server 2003 Enterprise Server

2, 3, 4, 5, 6, 7, or 8

Fiber channel

64-bit edition of Windows
Server 2003 Datacenter
Edition

2, 3, 4, 5, 6, 7, or 8

Fiber channel


Installing Cluster Service

The Windows Server 2003 Cluster Service is installed by default. Because the service is already installed, creating a cluster does not require the installation media or a reboot. The Cluster Administrator utility can be used to create a new cluster and to manage existing clusters on local and remote nodes.

Both the GUI-based Cluster Administrator and the command-line utility Cluster.exe can be used to create and manage clusters. Both tools can effectively manage a cluster, but Cluster.exe allows an administrator to create an unattended, scripted cluster installation. Cluster.exe provides too many arguments and switches to be discussed in detail here, so refer to Help and Support from the Start menu and search for "cluster.exe." Alternatively, at a command prompt, type cluster.exe /?. Later in this chapter, in the "Installing the First Node in the Cluster" section, basic Cluster.exe commands will be outlined.

A recommendation for cluster nodes is to have multiple network cards in each node so that one card can be dedicated to internal cluster communication (private network) while the other can be used only for client connectivity (public network) or for both public and private communication (mixed network). Cluster nodes equipped with only one network card must run the card in Mixed Network mode.

During a cluster installation, if shared storage is discovered, Cluster Service will default to installing the quorum resource on the smallest basic partition on the device. If no shared storage is available, a local or an MNS quorum will be created.

Working Through the Cluster Pre-Installation Checklist

Be sure to check the following before installing Cluster Service:

1.
Gather the network name for the cluster.

2.
Gather all necessary IP addresses for the cluster and for each network card in the cluster node.

3.
Before booting up the first server, connect, configure, and turn on all external storage devices if any are being used. You should also have the appropriate drivers that may be required for this external storage device.

4.
If multiple network cards are being used, rename the connections using easily identifiable names, such as Cluster Private Nic and Cluster Mix Nic, similar to what is shown in Figure 31.3.

Figure 31.3. Multiple network adapter configuration.

[View full size image]

5.
Create a Cluster Service account in the domain in which you are installing the cluster. It needs to be only a standard user account, but the password should never expire. During the cluster installation, the account will be given Local Administrator rights on the cluster nodes and will be given a few rights in the domain, such as Add Computer Accounts to the Domain.

6.
Choose your cluster configuration mode and choose the correlating quorum type during the cluster installation.

Installing the First Node in the Cluster

When a cluster is built, the first system to be built is considered the first node in the cluster. This system needs to be initially prepared as the primary system. When the primary system has been configured, additional nodes can be added to the cluster.

To install the first node in the cluster, follow these steps:

1.
Shut down both the cluster nodes and shared storage devices.

2.
Connect cables as required between the cluster nodes and shared storage devices.

3.
Connect each node's NICs to a network switch or hub using appropriate network cables.

4.
If a shared storage device is being used, power on the shared storage device and wait for the startup sequence to complete.

5.
Start the first node in the cluster. If a shared disk will be used, configure the adapter card's ID on each cluster node to a different number. For example, use ID 6 for node 1 and ID 7 for node 2.

6.
Log on with an account that has Local Administrator privileges.

7.
If the server is not a member of a domain, add the server to the correct domain and reboot as necessary.

8.
Configure each network card in the node with the correct network IP address information.

Network cards that will be used only for private communication should have only an IP address and subnet mask configured. Default Gateway, DNS, NetBIOS-related services (such as Client for Microsoft Networks), and WINS should not be configured. Also, uncheck the Register This Connection's Address in DNS box, as shown in Figure 31.4, on the DNS tab of the Advanced TCP/IP Settings page.

Figure 31.4. TCP/IP DNS configuration settings.

For network cards that will support public or mixed networks, configure all TCP/IP settings as they would normally be configured.

9.
If you're not already logged in, log on to the server using an account that has Local Administrator privileges.

10.
Click Start, Administrative Tools, Cluster Administrator, as shown in Figure 31.5.

Figure 31.5. Launching the Cluster Administrator utility.

[View full size image]

11.
When the Cluster Administrator opens, choose the Create New Cluster action and click OK.

12.
Click Next on the New Server Cluster Wizard Welcome screen to continue.

13.
Choose the correct domain from the Domain pull-down menu.

14.
Type the cluster name in the Cluster Name text box and click Next to continue.

15.
Type the name of the cluster node and click Next to continue. The wizard defaults to the local server, but clusters can be configured remotely. The cluster analyzer analyzes the node for functionality and cluster requirements, as shown in Figure 31.6. A detailed log containing any errors or warnings that can stop or limit the installation of the Cluster server is generated.

Figure 31.6. Cluster analyzer utility operations.

16.
Review the log and make changes as necessary; then click Re-analyze or click Next to continue.

17.
Enter the cluster IP address and click Next.

18.
Enter the Cluster Service account name and password and choose the correct domain. Click Next to continue.

Note

The Cluster Service account needs to be only a regular domain user, but specifying this account as the Cluster Service gives this account Local Administrator privileges on the cluster node and also delegates a few user rights, including the ability to act as a part of the operating system and add computers to the domain.

19.
On the Proposed Cluster Configuration page, review the configuration and choose the correct quorum type by clicking the Quorum button, as shown in Figure 31.7.

Figure 31.7. Choosing the cluster quorum configuration.

  • To create an MNS cluster, click the Quorum button on the Proposed Cluster Configuration page, choose Majority Node Set, and click OK.

  • If a SAN is connected to the cluster node, the Cluster Administrator will automatically choose the smallest basic NTFS volume on the shared storage device. Make sure the correct disk has been chosen and click OK.

  • If you're configuring a single-node cluster with no shared storage, choose the Local Quorum resource and click OK.

20.
Click Next to complete the cluster installation.

21.
After the cluster is created, click Next and then Finish to close the New Server Cluster Wizard and return to the Cluster Administrator.

Alternatively, you can create a cluster by using Cluster.exe. You can use the following to create a cluster called cluster1 on the server named Server1. This example uses a Cluster Service account called clustersvc@companyabc.com, using the 192.168.100.10 IP address and a class C subnet mask. Also the network card is renamed Cluster Mix Nic at a command prompt. The command is as follows:

Cluster.exe /CLUSTER:cluster1 /CREATE /NODE:server1 /USER:clustersvc@companyabc.com
/PASSWORD:password /IPADDRESS:192.168.100.10,255.255.255.0, "Cluster Mix Nic"

Then press Enter to create the cluster.

Adding Additional Nodes to a Cluster

A cluster in Windows Server 2003 Enterprise Edition can support up to four nodes. After the first server is installed in a cluster, additional nodes can be added to the cluster.

To add more nodes to a cluster, do the following:

1. | Log on to the desired cluster node using an account that has Local Administrator privileges.
2. | Click Start, Administrative Tools, Cluster Administrator.
3. | When the Cluster Administrator opens, choose Add Nodes to a Cluster and type the name of the cluster in the Cluster Name text box. Click OK to continue.
4. | When the Add Nodes Wizard appears, click Next to continue.
5. | Type in the server name of the next node and click Add.
6. | Repeat the preceding steps until you've entered all the additional nodes you want in the Selected Computer text box. Click Next to continue. The cluster analyzer will then analyze the additional nodes for functionality and cluster requirements.
7. | Review the log and make changes as necessary; then click Re-analyze or click Next to continue.
8. | Enter the Cluster Service account password and click Next to continue.
9. | Review the configuration on the Proposed Cluster Configuration page and click Next to configure the cluster.
10. | After the cluster is configured, click Next and then click Finish to complete adding additional nodes to the cluster.
11. | Select File, Close to exit the Cluster Administrator.


Managing Clusters

To manage a cluster effectively, an administrator must be familiar with managing cluster groups and resources using one or more cluster management applications. Microsoft provided two cluster management applications for Cluster Service: one GUI-based and one command linebased.

Cluster Administrator

The Cluster Administrator, shown in Figure 31.8, gives an administrator a GUI-based tool for managing clusters. This tool can be used to manage local and remote clusters, including tasks such as creating new clusters, adding nodes to existing clusters, and creating cluster resource groups or resources. This tool can also be used to remove (evict) nodes from a cluster and perform manual failovers of cluster groups.

Figure 31.8. Sample Cluster Administrator tool screen.

[View full size image]

The Cluster.exe Utility

Cluster.exe is a command-line utility that can be used to manage a local or remote cluster from a command line or a shell. This tool can be used to access a cluster when the GUI-based Cluster Administrator will not open. Additionally, this tool can be used in a script to remotely deploy or change cluster configurations.

Cluster Automation Server

The Cluster Automation server provides a mechanism for software developers and Independent Software Vendors (ISVs) to create custom cluster-management applications to enhance or provide administration of clusters. The Cluster Automation server provides a set of Component Object Model (COM) objects to allow developers to create scripts to automate the management of their clusters.

Configuring Failover and Failback

Clusters that contain two or more nodes automatically have failover configured for each defined cluster group when the second node and following nodes join the cluster. By manually adding additional nodes to existing cluster groups, the administrator can add failover functionality to every node in the cluster on a group-by-group basis. Failback is never configured by default and needs to be manually configured for each cluster group if desired. Failback allows a designated preferred server to always run a particular cluster group when it is available.

Cluster Group Failover Configuration

To create a failover and failback process, the cluster group failover configuration needs to be set up properly. Follow these steps to configure cluster group failover:

1.
Click Start, Administrative Tools, Cluster Administrator.

2.
When the Cluster Administrator opens, choose Open Connection to Cluster and type the name of the cluster in the Cluster Name text box. Click OK to continue. If the local machine is part of the cluster, enter . (period) as the cluster name, and the program will connect to the cluster running on the local machine.

3.
Right-click the appropriate cluster group and select Properties.

4.
Select the Failover tab and set the maximum number of failovers allowed during a predefined period of time. When the number of failovers is exceeded within the Period interval, shown as a threshold of 10 in Figure 31.9, Cluster Service will change the group to a failed state.

Figure 31.9. Setting failover thresholds for the cluster group.

5.
Click Next and then Finish to complete the failover configuration.

6.
Select File, Close to exit Cluster Administrator.

Cluster Group Failback Configuration

The cluster group failback process involves making configuration changes in the Cluster Administrator utility. Follow these steps to configure cluster group failback:

1. | Click Start, Administrative Tools, Cluster Administrator.
2. | When Cluster Administrator opens, choose Open Connection to Cluster and type the name of the cluster in the Cluster Name text box. Click OK to continue.
3. | Right-click the appropriate cluster resource group and select Properties.
4. | On the General tab, click the Modify button to select the preferred owners. Doubleclick the node or nodes you prefer the cluster group to run on and click OK to return to the cluster group's General tab.
5. | Select the Failback tab, choose the Allow Failback radio button, and set time options for allowing failback.
6. | Click Next and then Finish to complete the failback configuration.
7. | Select File, Close to exit Cluster Administrator.

Note

To reduce the chance of having a group failing back to a node during regular business hours after a failure, configure the failback schedule to allow failback only during nonpeak times or after hours using settings similar to those made in Figure 31.10.

Figure 31.10. Setting failback for a cluster file group.

Testing Clusters

After all the desired cluster nodes are added and failover and failback are configured for each cluster group to complete cluster installation, it is time to test cluster functionality. For these tests to be complete, failover and, when applicable, failback of cluster groups need to be tested. They can be tested by manual failover and also by taking a cluster node off the network by unplugging network cards. However, the cluster is not tested by disconnecting shared storage device connections because this may cause possible corruption in the shared storage data.

Note

Clusdiag.msi, located in the Windows Server 2003 Resource Kit, can be used to diagnose and test the cluster. It can also aid in troubleshooting failures by providing administrators reports based on prior testing.

Testing Cluster Group Manual Failover

To test the cluster group failover manually, follow these steps:

1. | Open Cluster Administrator, right-click the desired cluster group, and choose Take Offline.
2. | Right-click the same cluster group and choose Move Group. If the cluster contains more than two nodes, choose the node to which you want to move the group.
3. | Right-click the same cluster group and choose Bring Online.
4. | The group now should start on the node you chose in step 2. Repeat steps 13 for each cluster group, moving back and forth between all available cluster nodes.
5. | When testing is complete, move cluster groups to their desired cluster nodes and bring all groups online.
Initiating Failure of a Cluster Resource

To simulate a cluster resource failure, a cluster administrator can initiate a resource failure using the Cluster Administrator utility. This utility can be used to verify how a failing cluster resource will affect the cluster group.

To test the failure of a cluster resource, follow these steps:

1. | Open Cluster Administrator.
2. | Right-click the cluster resource you will manually fail and select Properties.
3. | Select the Advanced tab and note how many failures this resource will tolerate before it finally fails completely or fails the entire cluster group.
4. | Close the resource's property page.
5. | Right-click the cluster resource you will manually fail and choose Initiate Failure.
6. | Repeat the preceding steps as necessary to ensure proper operation during resource failure conditions.
7. | When testing is complete, move cluster groups to their desired cluster nodes and bring all groups online.
Initiating Cluster Node Network Failure

To simulate and verify how cluster groups will fail over during a cluster node network or network card failure, perform the following steps:

1. | Log on to the desired cluster node with Cluster Administrator or Local Administrator permissions.
2. | Click Start, Control Panel.
3. | Double-click the Network Connections applet.
4. | Right-click each of the cluster node's private network and public network adapters and choose Disable.
5. | On an available cluster node, log in using a Cluster Administrator account.
6. | Click Start, Administrative Tools, Cluster Administrator.
7. | If the Cluster Administrator does not connect to the cluster or connects to a different cluster, choose File, Open Connection.
8. | From the Active drop-down box, choose Open Connection to Cluster. Then, in the Cluster or Server Name drop-down box, type . (period) and click OK to connect.
9. | Verify that the network-disabled node appears as offline and that all cluster groups have failed over to other available cluster nodes.
10. | When testing is complete, enable all disabled network cards on the network-disabled node.
11. | Move cluster groups to their desired cluster nodes and bring all the groups online.

Maintaining Cluster Nodes

Applications are clustered due to the critical part they play in a business. Even though the highest availability and fault tolerance are needed, each cluster node will, at one point or another, require maintenance for hardware or software upgrades. To prepare a cluster node for maintenance, a few preliminary and post steps need to occur.

Pre-Maintenance Tasks

Before maintenance is run on a cluster node, several tasks need to be completed. To prepare a cluster node for maintenance, do the following:

1. | Whether you're planning a software or hardware upgrade, research to see whether the changes will be supported on a cluster node.
2. | Log on to a cluster node that will remain online using an account that has Administrative permissions on the cluster.
3. | Click Start, Administrative Tools, Cluster Administrator.
4. | If Cluster Administrator does not open to the correct cluster or does not open a cluster, pull down the Cluster Server menu and choose to connect to an existing cluster. Then enter the cluster's fully qualified domain name and click OK.
5. | Find the server that will be going offline for maintenance and double-click it.
6. | Double-click Active Groups.
7. | If there are any active groups, when appropriate (after hours or during a change control session) right-click each active group and choose Move Group. If there are more than two nodes in the cluster, choose the node you are taking offline for maintenance.
8. | Repeat step 7 for each remaining active group.
9. | In the right pane, right-click the appropriate node and choose Pause Node.
10. | Close Cluster Administrator.

Perform necessary maintenance, including any reboots if necessary. Check to see that all updates have been applied successfully and the server hardware and software are running as expected. When all checks are completed, you are ready to make this node available in the cluster.

Post-Maintenance Tasks

After maintenance has been conducted on a cluster, several tasks need to be completed. To perform follow-up maintenance, do the following:

1. | Log on to a cluster node that has remained online using an account that has Administrative permissions on the cluster.
2. | Click Start, Administrative Tools, Cluster Administrator.
3. | If Cluster Administrator does not open to the correct cluster or does not open to any cluster, pull down the Cluster Server menu and choose Connect to an Existing Cluster. Then enter the cluster's fully qualified domain name and click OK.
4. | Find the server that is paused for maintenance, right-click it, and choose Resume Node.
5. | In the right pane, double-click the cluster name at the top of the window.
6. | Double-click Groups.
7. | In the left pane, right-click a cluster group that you want running back in the updated node and choose Move Group. (If there are more than two nodes in the cluster, choose the upgraded node.)
8. | Repeat step 7 for any additional cluster groups you want running on the upgraded node. When finished selecting the cluster groups, click OK to execute.

Creating Additional Cluster Groups and Resources

The Cluster server supports multiple cluster groups that can be used to support several purposes. For instance, a cluster group can be created to consolidate a standalone file server to a virtual server running on the cluster or to run as a separate cluster application group. Also, some applications like Microsoft SQL Server 2000 may require separate cluster groups to operate efficiently. When additional cluster groups are necessary, they can be easily created using the Cluster Administrator program.

Creating Groups

To create new cluster groups, perform the following steps:

1.
Click Start, Administrative Tools, Cluster Administrator.

2.
When Cluster Administrator opens, choose Open Connection to Cluster and type the name of the cluster in the Cluster Name text box. Click OK to continue.

3.
Right-click the cluster and select New and then Group, as shown in Figure 31.11.

Figure 31.11. Adding a new group for cluster configuration.

[View full size image]

4.
Enter the appropriate information to complete the group addition.

5.
Click Next and then Finish after all groups have been created.

6.
Select File, Close to exit Cluster Administrator.

Creating New Resources

To create new resources, follow these steps:

1. | Click Start, Administrative Tools, Cluster Administrator.
2. | When Cluster Administrator opens, choose Open Connection to Cluster and type the name of the cluster in the Cluster Name text box. Click OK to continue.
3. | Right-click the cluster and select New Resource.
4. | Type in the appropriate name and description for the resource.
5. | Choose the correct resource type and which cluster group it will reside in.
6. | Choose which servers can run the resource and click Next to continue.
7. | Choose which existing resources the new resource will depend on and click Next to continue.
8. | Enter any remaining resource parameters to complete the resource creation because certain resources have resource requirements. For instance, a network name resource depends on an IP address resource, so an IP resource must first be configured in a cluster group before a network name resource will be allowed.
9. | In Cluster Administrator, right-click the new resource and bring online.
10. | Select File, Close to exit Cluster Administrator.

Changing the Cluster Service Account Password

In previous versions of Cluster Service, changing the Cluster Service account password required bringing the Cluster Service down on each node and manually changing the cluster password using the Change Password applet. Then the Cluster Service logon credentials had to be changed in the Services applet in the Control Panel.

Starting with Windows Server 2003, the Cluster Service account password can be changed with the cluster online. Do not, however, change the password using the Active Directory Users and Computers snap-in or the Windows security box if logged in with that account. Instead, run the Cluster.exe command-line utility from a server on the network. At a command prompt, enter the following command to complete the password-changing operation:

Cluster.exe /cluster:clustername /changepass:currentpassword, newpassword

Then press Enter to continue.

Note

All nodes in the cluster must be running on the Windows Server 2003 operating system for this password-changing command to work.

Moving Cluster Groups

Moving a cluster group from one node to another makes the resources unavailable during the time necessary to take the group offline and bring it online on the next node.

If the administrator moves a group for the purposes of performing maintenance on a node, she must be sure to pause the node after all cluster groups are moved off. This ensures that no cluster groups will move to this node until the administrator resumes node operation after maintenance is performed.

If you want to move a group, right-click the cluster group and select Move Group. If more than two nodes are possible owners of this cluster group, choose the appropriate node to move this group to.

Removing a Node from a Cluster

Cluster nodes can be removed from a cluster for a number of reasons, and this process can be accomplished quite quickly.

Note

If you're removing nodes on an MNS cluster, be sure that a majority of the nodes remain running to keep the cluster in a working state.

To remove a node from a cluster, follow these steps:

1.
Click Start, Administrative Tools, Cluster Administrator.

2.
When the Cluster Administrator opens, choose Open Connection to Cluster and type the server name of a node in the cluster that will remain up and running during this process.

3.
Double-click the node that will be removed from the cluster and click Active Groups.

4.
If any groups are running on the node, at the appropriate time move these groups to other available nodes.

5.
Right-click the cluster node and choose Stop Cluster Service.

6.
Right-click the cluster node and choose Evict Node, as shown in Figure 31.12.

Figure 31.12. Evicting a node.

[View full size image]

7.
Confirm the eviction process by choosing Yes, and the node will be removed from the cluster immediately.

8.
From a command line, run the following command to remove a node from a cluster:

Cluster.exe /cluster:clustername node nodename /evict

Then press Enter to evict the node.

9.
Select File, Close to exit Cluster Administrator.


Backing Up and Restoring Clusters

To successfully back up and restore the entire cluster or a single cluster node, the cluster administrator must first understand how to troubleshoot, back up, and restore a stand-alone Windows Server 2003. The process of backing up cluster nodes is the same as for a standalone server, but restoring a cluster may require additional steps or configurations that do not apply to a standalone server. Detailed Windows Server 2003 backup and restore techniques and disaster recovery planning best practices are discussed in Chapter 32, "Backing Up a Windows Server 2003 Environment," and Chapter 33, "Recovering from a Disaster." This section focuses mainly on backing up and restoring cluster nodes.

To be prepared to recover different types of cluster failures, you must take the following steps:

1.
For all cluster nodes (single, MNS, and single-quorum nodes), do the following:

  • Back up each cluster node's local disks.

  • Back up each cluster node's system state.

  • Back up the cluster quorum from any node running in the cluster.

  • Back up each cluster node's disks signatures and volume information.

2.
For clusters with shared storage devices, do the following in addition to Step 1:

  • On the individual cluster nodes, document storage adapter settings, including manufacturer name, model number, and configurations such as SCSI ID and IRQ when applicable. Also, note which motherboard slot the nodes are located in.

  • On shared storage devices with built-in RAID controllers, record disk array configurations, including array type, array members, hot spares, volume definition, disk IDs, and LUNs.

  • Back up shared cluster disks.

To back up cluster nodes and data on their storage devices, you use the Windows Server 2003 Backup utility (ntbackup.exe). For detailed information about this utility and the different backup options available, refer to Chapters 32 and 33.

Cluster Node Backup Best Practices

As a backup best practice for cluster nodes, administrators should strive to back up everything as frequently as possible. Because cluster availability is so important, here are some recommendations for cluster node backup:

  • Back up each cluster node's system state daily and immediately before and after a cluster configuration change is made.

  • Back up cluster local drives and system state daily if the schedule permits or weekly if daily backups cannot be performed.

  • Back up cluster shared drives daily if the schedule permits or weekly if daily backups cannot be performed.

  • Use the MSCS Recovery Utility (ClusterRecovery) utility provided in the Windows Server 2003 Resource Kit to save configuration information such as checkpoint files. These checkpoint files are stored in the quorum but are still used to update Registry settings when resources are moved or failed over to another cluster node.

  • Perform an ASR backup on each node following the creation of a new cluster, monthly, and whenever a change is made on the node. For instance, back up when a new cluster application is installed or when a disk is added or removed from a cluster.

Automated System Recovery Backup

Automated System Recovery has two parts: the ASR backup and the ASR restore. An ASR backup can be used to satisfy one of a cluster node's backup requirements, backing up disk signatures and volume information. When a disk signature is overwritten and the cluster can no longer identify shared disks or read volume information, the administrator needs to restore cluster disk signatures using ASR restore. This approach, however, is a last resort and should be used only if no cluster nodes can communicate with the shared devices and all other cluster restore techniques have been exhausted.

An ASR backup of a cluster node contains a disk signature or signatures and volume information; the current system state, which includes the Registry, cluster quorum, boot files, and the COM+ class registration database; system services; and a backup of all local disks containing operating system files, including system and boot partitions. Currently, the only way to back up disk signatures is to create an ASR backup from the local server console using Windows Server 2003 Backup.

To perform an ASR backup, an administrator needs a blank floppy disk and a backup device; either a tape device or disk will suffice. Using recordable CDs and devices for use with the Backup utility is not yet supported, so if no tape device is available, the backup can be run to a backup file on a local or a network drive. Saving the backup file to a network drive helps to ensure that the media can be accessed when an ASR restore is necessary. One point to keep in mind is that an ASR backup will back up each local drive that contains the operating system and any applications installed. For instance, if the operating system is installed on drive C: and MS Office is installed on drive D:, both of these drives will be completely backed up. Although this can greatly simplify restore procedures, it requires additional storage and increases backup time. Using a basic installation of Windows Server 2003 Enterprise server with only the Cluster Service installed, an ASR backup averages 1.3GB in size.

To create an ASR backup, perform the following steps:

1.
Log on to the cluster node with an account that has the right to back up the system. (Any Local Administrator, Domain Administrator, or Cluster Service account has the necessary permissions to complete the operation.)

2.
Click Start, All Programs, Accessories, System Tools, Backup.

3.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink. After you change to Advanced mode, the window should look similar to Figure 31.13.

Figure 31.13. Windows Backup in Advanced mode.

[View full size image]

4.
Click the Automated System Recovery Wizard button to start the Automated System Recovery Preparation Wizard.

5.
Click Next after reading the Automated System Recovery Preparation Wizard Welcome screen.

6.
Choose your backup media type and choose the correct media tape or file. If you're creating a new file, specify the complete path to the file, and the backup will create the file automatically. Click Next to continue.

7.
If the file you specified resides on a network drive, click OK at the warning message to continue, as shown in Figure 31.14.

Figure 31.14. Warning when selecting a resource for backup.

8.
Click Finish to complete the Automated System Recovery Preparation Wizard and to start the backup.

9.
After the tape or file backup portion completes, the ASR backup prompts you to insert a floppy disk that will contain the recovery information. Insert the disk and click OK to continue.

10.
Remove the floppy disk as requested and label the disk with the appropriate ASR backup information. Click OK to continue.

11.
When the ASR backup is complete, click Close on the Backup Progress windows to return to the backup program or click Report to examine the backup report.

ASR backups should be performed periodically and immediately following any hardware changes to a cluster node, including changes on a shared storage device or local disk configuration. The information contained in the ASR floppy disk is also stored on the backup media. The ASR floppy contains two files, asr.sif and asrpnp.sif, that can be restored from the backup media and copied to a floppy disk when an ASR restore is necessary.

Backing Up the Cluster Quorum

The cluster quorum is backed up when the system state of any active cluster node is backed up. This backup can be used to restore a cluster node to operation when cluster database or log corruption occurs or when the previous state of a cluster needs to be rolled back up to every cluster node. The cluster quorum should be backed up frequently to ensure that the latest version of the cluster configuration is saved. To back up the cluster quorum, follow the steps outlined in the next section.

Backing Up the Cluster Node System State

Each cluster node's system state should be backed up regularly and before and after any hardware or software changes, including cluster configuration changes. This backup will contain the cluster quorum, local server Registry, COM+ registration database, and boot files necessary to start the system. On a domain controller, the system state will also contain the Active Directory database and the SYSVOL folder.

To back up the system state, perform the following steps:

1.
Log on to the cluster node using an account that has the right to back up the system. (Any Local Administrator, Domain Administrator, or Cluster Service account has the necessary permissions to complete the operation.)

2.
Click Start, All Programs, Accessories, System Tools, Backup.

3.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink. After you change to Advanced mode, the window should look like the one in Figure 31.13.

4.
Click the Backup Wizard (Advanced) button to start the Backup Wizard.

5.
Click Next on the Backup Wizard Welcome screen to continue.

6.
On the What to Back Up page, choose the Only Back Up the System State Data button, shown in Figure 31.15, and click Next to continue.

Figure 31.15. Choosing the correct option for backup.

7.
Choose your backup media type and choose the correct media tape or file. If you're creating a new file, specify the complete path to the file, and the backup will create the file automatically. Click Next to continue.

8.
If the file you specified resides on a network drive, click OK at the warning message to continue.

9.
Click Finish to complete the Backup Wizard and start the backup.

10.
When the backup is complete, review the backup log for detailed information and click Close on the Backup Progress window when finished.

Backing Up the Local Disks on a Cluster Node

The cluster node local disks should be backed up regularly and, if possible, should be backed up with the system state. This allows both the system state and local disks to be recovered if a complete server failure should occur.

To back up a cluster node's local disks, perform the following steps:

1.
Log on to the cluster node with an account that has the right to back up the system. (Any Local Administrator, Domain Administrator, or the Cluster Service account has the necessary permissions to complete the operation.)

2.
Click Start, All Programs, Accessories, System Tools, Backup.

3.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink. After you change to Advanced mode, the window should look like the one in Figure 31.13.

4.
Click the Backup Wizard (Advanced) button to start the Backup Wizard.

5.
Click Next on the Backup Wizard Welcome screen to continue.

6.
On the What To Back Up page, choose the Back Up Selected Files, Drives, or Network Data button and click Next to continue.

7.
In the Items To Back Up window, shown in Figure 31.16, expand Desktop\My Computer and choose each of the local drives.

Figure 31.16. Choosing items to back up.

8.
Choose your backup media type and choose the correct media tape or file. If you're creating a new file, specify the complete path to the file, and the backup will create the file automatically. Click Next to continue.

9.
If the file you specified resides on a network drive, click OK at the warning message to continue.

10.
Click Finish to complete the Backup Wizard and start the backup.

11.
When the backup is complete, review the backup log for detailed information and click Close on the Backup Progress window when finished.

Backing Up Shared Disks on a Cluster

Shared storage disks can be backed up in a few different ways. The first way is to back up the disks from the node that is currently hosting them. This way, the disks can be backed up using the same process used to back up local disks, except the shared disks are chosen in the Backup Selection window.

The second way requires knowledge of the disk drive letters or mount points; it can be run and scheduled from any machine on the network using an account with permission to back up the cluster disks. If the drive letters are known, the cluster administrator can create network places that point to the cluster disk's administrative hidden shares. Alternatively, the hidden drive shares can be mapped to a local drive letter and backed up using the appropriate mapped network drives.

For example, in a cluster called CLUSTER1 with nodes named SERVER1 and SERVER2 and two shared disks named Q and F, the administrator can back up the drives by creating a network place or mapping a drive to \\cluster1\F$ and \\cluster1\Q$. If the disk resources are currently running in groups active on SERVER1, the administrator can connect to those hidden drive shares using the UNC of \\SERVER1\F$ and \\SERVER1\Q$. Using the cluster name or the network name of the particular cluster group containing a disk resource is preferred because the path will be absolute regardless of which node the group is active on.

Note

If shared disks are defined as volume mount points, backing up the drive also backs up data under the mount points.

Restoring a Single-Node Cluster When the Cluster Service Fails

When Cluster Service on a single node fails and will not start, it is usually a sign of corruption in the local cluster database file CLUSDB. In the interest of time, an administrator can replace the CLUSDB file with the latest CHKxxx.tmp file from the quorum disk's MSCS directory.

To replace the CLUSDB file, follow these steps:

1.
Log on to the cluster node using an account that has the right to back up the system. (Any Local Administrator, Domain Administrator, or Cluster Service account has the necessary permissions to complete the operation.)

2.
Open Cluster Administrator on an available cluster node. Then check to ensure that all cluster groups are running properly to verify that the Cluster Service problem is only on a single node.

3.
If only one node is experiencing Cluster Service startup problems, log on to the server console and click Start, All Programs, Administrative Tools, Services.

4.
In the Services applet, locate Cluster Service and double-click it.

5.
On the General tab of the property page for Cluster Service, disable the Startup Type service. Click OK to save changes.

6.
Reboot the server to release any file locks on the CLUSDB file.

7.
When the server completes the reboot process, log on with a Cluster Administrator account.

8.
Click Start, Run.

9.
Connect to the cluster quorum disk by using the UNC path \\<clustername>\ <quorum_drive_letter>$. For example, in a cluster named cluster1 with a quorum disk named Q, use the path \\cluster1\Q$.

10.
Double-click the MSCS directory.

11.
Choose View, Details in the Explorer window.

12.
Locate the file named CHKxxx.tmp with the latest time stamp, similar to the one shown in Figure 31.17.

Figure 31.17. Choosing a backup set for restoral.

[View full size image]

13.
Right-click the file and choose Copy. Then close the Explorer window.

14.
Click Start, Run.

15.
Type in the full path to the cluster directory and click OK. The default path is C:\windows\cluster, where C is the system drive and windows is the %SystemRoot% directory.

16.
Locate the CLUSDB file, right-click it, and choose Rename.

17.
Rename the file to CLUSDB.old and press Enter to save. If the file cannot be renamed, make sure Cluster Service is set to disable, reboot the server, and then try again.

18.
Choose Edit, Paste in the Explorer window. The CHKxxx.tmp file should now be copied in the c:\windows\cluster directory.

19.
Locate the CHKxxx.tmp file, right-click it, and choose Rename.

20.
Rename the file to CLUSDB and press Enter to save. If the file cannot be renamed, make sure the Cluster Service is set to disable, reboot the server, and then try again.

21.
Close the Explorer window.

22.
Click Start, All Programs, Administrative Tools, Services.

23.
In the Services applet, locate Cluster Service and double-click it.

24.
On the General tab of Cluster Service's property page, change the Startup Type service to Automatic. Click OK to save your changes.

25.
Right-click Cluster Service and choose Start.

26.
When Cluster Service starts, move the appropriate group or groups to the recovered node to test failover functionality.

If this process does not restore operational status to Cluster Service, restore the system state from a previous backup by following these steps:

1.
Click Start, All Programs, Accessories, System Tools, Backup.

2.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking on the Advanced Mode hyperlink. After you change to Advanced mode, the window should look like the one in Figure 31.13.

3.
Click the Restore Wizard (Advanced) button to start the Restore Wizard.

4.
Click Next on the Restore Wizard Welcome screen to continue.

5.
On the What to Restore page, select the appropriate cataloged backup media, expand the catalog selection, and check System State, as shown in Figure 31.18. Click Next to continue.

Figure 31.18. Choosing to restore the system state.

6.
If the correct tape or file backup media does not appear in this window, cancel the restore process. Then, from the Restore Wizard page, locate and catalog the appropriate media and return to the restore process from step 1.

Note

Refer to Chapter 33 for information on how to catalog tape and file backup media.

7.
On the Completing the Restore Wizard page, click Finish to start the restore.

8.
When the process is complete, review the log for detailed information and click Close when finished.

9.
Reboot the restored cluster node as prompted.

10.
When Cluster Service starts, move the appropriate group or groups to the recovered node to test failover functionality.

Restoring a Single Node After a Complete Server Failure

When a single node fails, whether because of hardware problems or software corruption that cannot be repaired in a reasonable amount of time, the node must be rebuilt from scratch. After any hardware problems are resolved, the organization can decide what the best approach to server recovery will be. The two basic approaches to node recovery are outlined next.

Evicting and Rebuilding the Failed Node

This first node recovery process evicts the failed node from the cluster and requires the cluster administrator to rebuild the cluster node from scratch, rejoin the node to the cluster, install any cluster applications, and finally reconfigure the cluster's group failover and failback configurations.

To evict and rebuild the failed node, follow these steps:

1. | Shut down the failed cluster node.
2. | On an available cluster node, log in using a Cluster Administrator account.
3. | Click Start, Administrative Tools, Cluster Administrator.
4. | If Cluster Administrator does not connect to the cluster or connects to a different cluster, choose File, Open Connection.
5. | From the Active drop-down box, choose Open Connection to Cluster. Then, in the Cluster or Server Name drop-down box, type . (period) and click OK to connect.
6. | In the left pane of the Cluster Administrator window, right-click the offline cluster node and choose Evict Node.
7. | When the node is evicted, close Cluster Administrator and immediately start a backup of the local node's system state. Refer to the previous section "Backing Up the Cluster Node System State" for detailed steps for system state backup.
8. | On the failed node, install a clean copy of Windows Server 2003 Enterprise or Datacenter server.
9. | After it is loaded, configure the server to join the correct domain and configure all local drive letters and network card IP addresses as previously configured on the original cluster node. Then reboot if necessary.
10. | Follow the steps to rejoin the cluster as outlined in the previous section, "Adding Additional Nodes to a Cluster."
11. | After the node rejoins the cluster, install any cluster applications as outlined in the vendor's installation guide for cluster installation.
12. | Configure cluster group failover and failback as necessary and move cluster groups to their preferred node.
Restoring the Failed Node Using the ASR Restore

To restore the failed node using the ASR restore, follow these steps:

1. | Shut down the failed cluster node.
2. | On an available cluster node, log in using a Cluster Administrator account.
3. | Click Start, Administrative Tools, Cluster Administrator.
4. | If Cluster Administrator does not connect to the cluster or connects to a different cluster, choose File, Open Connection.
5. | From the Active drop-down box, choose Open Connection to Cluster. Then, in the Cluster or Server Name drop-down box, type . (period) and click OK to connect.
6. | Within each cluster group, make sure to disable failback to prevent these groups from failing over to a cluster node that is not completely restored. Close Cluster Administrator.
7. | Locate the ASR floppy created for the failed node or create the floppy from the files saved in the ASR backup media. For information on creating the ASR floppy from the ASR backup media, refer to Help and Support from any Windows Server 2003 Help and Support tool.
8. | Insert the operating system CD in the failed server and start the server.
9. | If necessary, when prompted, press F6 to install any third-party storage device drivers. This includes any third-party disk or tape controllers that Windows Server 2003 will not recognize.
10. | Press F2 when prompted to perform an automated system recovery.
11. | When prompted, insert the ASR floppy disk and press Enter.
12. | The operating system installation will proceed by restoring disk volume information and reformatting the volumes associated with the operating system. When this process is complete, restart the server as requested by pressing F3 and then Enter in the next window.
13. | After the system restarts, press a key if necessary to restart the CD installation.
14. | If necessary, when prompted, press F6 to install any third-party storage device drivers. This includes any third-party disk or tape controllers that Windows Server 2003 will not recognize.
15. | Press F2 when prompted to perform an automated system recovery.
16. | When prompted, insert the ASR floppy disk and press Enter.
17. | This time, the disks can be properly identified and will be formatted, and the system files will be copied to the respective disk volumes. When this process is complete, the ASR restore will automatically reboot the server. Remove the ASR floppy disk from the drive. The graphic-based OS installation will begin.
18. | If necessary, specify the network location of the backup media using a UNC path and enter authentication information if prompted. The ASR backup will attempt to reconnect to the backup media automatically but will be unable if the backup media are on a network drive.
19. | When the media are located, open the media and click Next. Then finish recovering the remaining ASR data.
20. | When the ASR restore is complete, if any local disk data was not restored with the ASR restore, restore all local disks.
21. | Click Start, All Programs, Accessories, System Tools, Backup.
22. | If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink. After you change to Advanced mode, the window should look like the one in Figure 31.13.
23. | Click the Restore Wizard (Advanced) button to start the Restore Wizard.
24. | Click Next on the Restore Wizard Welcome screen to continue.
25. | On the What To Restore page, select the appropriate cataloged backup media, expand the catalog selection, and check each local drive. Click Next to continue.
26. | If the correct tape or file backup media do not appear in this window, cancel the restore process. Then locate and catalog the appropriate media from the Restore Wizard page and return to the restore process from step 23. Note Refer to Chapter 33 for information on how to catalog tape and file backup media.
27. | On the Completing the Restore Wizard page, click Finish to start the restore. Because you want to restore only what ASR did not, you do not need to make any advanced restore configuration changes.
28. | When the restore is complete, reboot the server as prompted.
29. | After the reboot is complete, log on to the restored cluster node and check cluster node functionality.
30. | If everything is working properly, open Cluster Administrator and configure all cluster group failover and failback configurations.
31. | Move cluster groups to their preferred node and close Cluster Administrator.

Restoring an Entire Cluster to a Previous State

Changes to a cluster should be made with caution and, if at all possible, should be made in a lab environment first. When cluster changes have been implemented and deliver undesirable effects, the way to roll back the cluster configuration to a previous state is to restore the cluster quorum to all nodes. This process is simpler than it sounds and is performed from only one node. There are only two disadvantages to this process:

  • All the cluster nodes that were members of the cluster previously need to be currently available and operational in the cluster. For example, if Cluster1 was made up of Server1 and Server2, both of these nodes need to be active in the cluster before the previous cluster configuration can be rolled back.

  • To restore a previous cluster configuration to all cluster nodes, the entire cluster needs to be taken offline long enough to restore the backup, reboot the node from which the backup was run, and manually start Cluster Service on all remaining nodes.

Note

If a cluster node is in a failed state, the cluster configuration cannot be rolled back. Refer to the "Restoring a Single Node After a Complete Server Failure" or the "Restoring the Failed Node Using the ASR Restore" sections to restore a failed cluster node to operational status and then restore a previous cluster configuration as shown here.

To restore an entire cluster to a previous state, perform the following steps:

1.
Log on to the cluster node using an account that has the right to back up the system. (Any Local Administrator, Domain Administrator, or Cluster Service account has the necessary permissions to complete the operation.)

2.
Click Start, All Programs, Accessories, System Tools, Backup.

3.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink. After you change to Advanced mode, the window should look like the one in Figure 31.13.

4.
Click the Restore Wizard (Advanced) button to start the Restore Wizard.

5.
Click Next on the Restore Wizard Welcome screen to continue.

6.
On the What To Restore page, select the appropriate cataloged backup media, expand the catalog selection, and check System State (refer to Figure 31.18). Click Next to continue.

7.
If the correct tape or file backup media does not appear in this window, cancel the restore process. Then, from the Restore Wizard page, locate and catalog the appropriate media and return to the restore process from step 4.

8.
On the Completing the Restore Wizard page, select the Advanced button to configure advanced restore settings.

9.
On the Where To Restore page, choose to restore files to the original location and click Next.

10.
A warning message will pop up stating that the restoring system state will overwrite the current system state. Click OK to continue.

11.
On the How To Restore page, choose the Leave Existing Files (Recommended) radio button and click Next to continue.

12.
On the Advanced Restore Options page, check the Restore the Cluster Registry to the Quorum Disk and All Other Nodes box, similar to the options selected in Figure 31.19, and click Next to continue.

Figure 31.19. Selecting options for restoral.

13.
A warning message pops up stating that this restore will replace the master version of the cluster quorum and will stop Cluster Service on all the other nodes in the cluster. Click Yes to continue.

14.
On the Completing The Restore Wizard page, click Finish to start the restore.

15.
When the process is complete, review the log for detailed information and click Close when finished.

16.
Reboot the restored cluster node as prompted.

17.
After the restored node completes rebooting and the previous cluster configuration is restored, start Cluster Service on all the remaining cluster nodes.

18.
Move cluster groups as desired and close Cluster Administrator.

Restoring Cluster Nodes After a Cluster Failure

Cluster nodes can be restored after a cluster failure using a combination of the previously described restore steps, with a few added steps. If each cluster node can start but Cluster Service cannot start on any node, there is most likely a problem with the quorum drive or quorum data.

To restore the cluster nodes in this situation, follow these steps:

1. | To restore the quorum data, follow the steps outlined in the section titled "Restoring a Single-Node Cluster When the Cluster Service Fails."
2. | After the system state restore is completed, if Cluster Service starts on the first node, start Cluster Service on all the remaining nodes. If Cluster Service does not start, there may be a problem with the cluster quorum drive. Make any necessary repairs on the cluster quorum drive and restore the cluster quorum as outlined in the section "Restoring a Single-Node Cluster When the Cluster Service Fails." If Cluster Service still does not start, follow the instructions in the Windows Server 2003 Help and Support article named "Recover from a Corrupted Quorum Log or Quorum Disk."

When all nodes in the cluster are non-operational and the cluster nodes need to be rebuilt from scratch, follow these steps:

1. | Power off all nodes in the cluster.
2. | Power on only the cluster node and perform an ASR restore as outlined in the section "Restoring the Failed Node Using the ASR Restore." This restore should restore the node and Cluster Service and basic cluster functionality.
3. | Restore any missing local disk data and cluster disk data.
4. | Perform ASR and local disk restores on remaining cluster nodes to restore complete cluster functionality.


Upgrading Cluster Nodes

Windows Server 2003 Cluster server is compatible with previous versions of Microsoft Cluster Service and can accommodate node operating system upgrades. Windows NT 4.0 clusters must be taken offline before upgrading to Windows Server 2003 clusters, whereas Windows 2000 clusters can be upgraded to Windows Server 2003 while online, utilizing the rolling upgrade method. Before a rolling upgrade can be performed, each resource in the cluster must be checked to see whether it can be upgraded during a rolling upgrade.

Note

Resources that do not allow rolling upgrades are IIS, FTP, DHCP, WINS, SMTP, and NNTP services, just to name a few. For detailed instruction on how to upgrade clusters containing these resources, refer to the Help and Support in the Windows Server 2003 operating system and search for "resource behavior during rolling upgrades" and "last node rolling upgrades."

Rolling Upgrades

A rolling upgrade allows a single cluster node to be taken offline for an operating system upgrade while the other nodes in the cluster function on the original OS version. On a standalone server, this is referred to as an inplace upgrade. When the upgraded node is back online with the new operating system, the Cluster server is already installed and configured. Cluster groups running on the other nodes can then be moved to the upgraded node, thus enabling administrators to upgrade the remaining nodes in the cluster.

Before attempting a rolling upgrade, the cluster administrator must research all the applications and resources in the cluster to ensure they can be supported during a rolling upgrade. If such an upgrade is not an option, the cluster nodes can be upgraded using the last node rolling upgrade method.

Last Node Rolling Upgrade

The last node rolling upgrade is a process created to upgrade clusters that contain resources that are unsupported during standard rolling upgrades. In this type of upgrade, the administrator moves all the groups containing resources that are unsupported in a standard rolling upgrade to a single cluster node. Then she upgrades all other nodes in the cluster. After all the other nodes are upgraded, she moves the groups with the unsupported resources to the upgraded nodes. Then the administrator performs an operating system upgrade on the last node and redistributes all the cluster groups as necessary.


Installing Network Load Balancing Clusters

An NLB cluster can be created easily using the Network Load Balancing Manager utility provided with the Windows Server 2003 Administrative Tools. NLB clusters can also be created using the network interface card property pages or at a command prompt using NLB.exe. To properly configure an NLB cluster, the administrator needs to research the type of network traffic the load-balanced application or service will utilize. For example, to load-balance standard Web traffic, the cluster needs to support TCP port 80, and for Terminal Services, the cluster needs to support TCP port 3389.

NLB Applications and Services

Network load balancing is well equipped to distribute user connections and create fault tolerance for a number of different applications and network services. Because NLB does not replicate data across cluster nodes, using applications that require access to local data that can be changed by the end users is not a good choice. For example, file servers that store user data directories or databases are not a good choice because a user may save a file or change some data within a database while connected to one node and later reconnect to a different node to find his file missing or the changes made to the database are nonexistent.

Applications well suited for NLB clusters are Web sites serving static content or dynamic content built from a back-end database running outside the NLB cluster. Also, Windows Server 2003 Terminal servers, VPN servers, Internet Security and Acceleration servers, and streaming media servers are well suited to be deployed on NLB clusters.

Because the most important part of an NLB deployment is determining what cluster operation mode and port rules need to be used for the load-balanced application to function correctly, the cluster administrator must understand the application thoroughly. It's important to read the vendor's application documentation regarding how the client communicates with the application. For instance, certain applications use cookies or other stateful session information that can be used to identify a client throughout the entire session. As a result, applications configured to prompt users for authentication upon starting a session will fail if the user's future requests are sent to a different cluster node that has not authenticated the user. Knowing these considerations in advance will help determine the required settings that need to be configured using cluster port rules and the filtering mode.

Creating Port Rules

When an NLB cluster is created, one general port rule is also created for this cluster. The port rule or rules define what type of network traffic the cluster will load-balance across the cluster nodes. The Port Rules Filtering option defines how the traffic will be balanced across each individual node. As a best practice, limiting the allowed ports for the clustered IP addresses to only those needed by the cluster load-balanced applications can improve overall cluster performance and security. In an NLB cluster, because each node can answer for the clustered IP address, all inbound traffic is received at each node. When a node receives the request, it either handles the request or drops the packet if another node already has a session with a source client. If a port rule does not define how traffic will be handled for a particular TCP or UPD port, traffic on those ports will be handled by the cluster node with the lowest host priority.

When an administrator creates port rules that allow only specific ports to the clustered IP address and an additional rule blocking all other ports and ranges, the cluster nodes can quickly eliminate and drop packets that do not meet the port rules, thereby improving performance by blindly dropping any packets not allowed by the cluster. The security benefit is that because only a specific port or service is available on the clustered IP address, monitoring that server and maintaining security updates are simpler.

Port Rules Filtering Mode and Affinity

Within a cluster port rule, the NLB administrator must configure the appropriate filtering mode. This allows the administrator to specify whether only one node or multiple nodes in the cluster can respond to requests from a single client throughout a session. There are three filtering modes: Single Host, Disable Port Range, and Multiple Host.

The Single Host Mode

The Single Host filtering mode provides network traffic meeting the port rule criteria to only one node in the cluster. An example is an IIS Web farm in which only one server has a Secure Sockets Layer (SSL) certificate for a secure Web site. In this case, creating a rule to allow port TCP 443 (SSL port) using single host filtering isolates this traffic to the node with the certificate installed.

The Disable Port Range Mode

The Disable Port Range filtering mode tells the cluster which ports not to listen on and to drop these packets without investigation. Administrators should configure port rules and use this filter mode for ports and port ranges that do not need to be load-balanced across the cluster nodes.

The Multiple Host Mode

The Multiple Host filtering mode is probably the most commonly used filtering mode and is also the default. This mode allows traffic to be handled by all the nodes in the cluster. When traffic is balanced across multiple nodes, the application requirements define how the affinity mode should be set.

There are three types of multiple host affinities:

  • None This affinity type can send a unique client's requests to all the servers in the cluster during the session. This can speed up server response times but is well suited only for serving static data to clients. This affinity type works well for general Web browsing and read-only file and FTP servers.

  • Class C This affinity type routes traffic from a particular class C address space to a single NLB cluster node. This mode is not used too often but can accommodate client sessions that do require stateful data. This affinity does not work well if all the client requests are proxied through a single firewall.

  • Single This affinity type is the most widely used. After the initial request is received by the cluster nodes from a particular client, that node will handle every request from that client until the session is completed. This affinity type can accommodate sessions that require stateful data.

Avoiding Switch Port Flooding

Because each node in an NLB cluster answers for incoming traffic, the cluster nodes do not allow a switch to cache their network card MAC address because the cluster nodes want to determine how to route the incoming packets. Because the network switch cannot cache the MAC address associated with the cluster IP addresses, it broadcasts each incoming packet on every port of the switch, which triggers each device connected to respond. When there is heavy traffic going to the cluster, a network switch can become flooded with requests, decreasing performance.

To reduce the risk of switch flooding, the NLB nodes should be connected to an isolated switch or should be configured in a single VLAN if the switch and network support VLANs. For detailed information regarding VLAN configuration and avoiding switch flooding, refer to the network switch documentation.

Using Cluster Operation Mode

There are two cluster operation modes: Unicast and Multicast. Most network traffic is handled through Unicast mode. Clients and servers maintain a one-to-one network connection. Multicast networking allows a server to send out information to one multicast address that is then processed by a number of clients. To receive multicast data, a client joins a multicast group associated with the multicast address. Common applications that use multicast are streaming video Web sites, Internet radio, and Internet training or college courses.

Configuring Network Cards for NLB

Configuring the network cards on the NLB cluster nodes is the first step in building the cluster. Although these steps can be performed during cluster creation using the NLB Manager, the same result can be achieved by editing the TCP/IP properties of each of the cluster node's network cards.

Because many cluster installations utilize Unicast operation mode, this causes some limitations and network overhead on the cluster nodes. When a single network card is used in Unicast mode, the NLB Manager does not run from the local console, requiring the administrator to configure and manage the cluster from a non-cluster node or use the network card's TCP/IP and network load balancing property pages or the command-line tool NLB.exe. Also, due to the configuration, the network adapter's dedicated IP MAC address is replaced with the cluster IP MAC address, causing additional network traffic for all nodes in the cluster when communication is requested for the dedicated IP address.

Best practice for NLB cluster nodes running in Unicast mode is to have two network cards to allow host communication to occur on one NIC while cluster communication is isolated on the cluster NIC. Multiple NICS can also add greater flexibility when it comes to controlling traffic and managing network security.

Using the Network Load Balancing Manager to Create a Cluster

Using the Network Load Balancing Manager is the simplest method of creating a cluster. If the NLB Manager is used, all additional cluster and dedicated IP addresses will be added to the respective cluster node when it joins the cluster. Adding additional nodes to the cluster is also simplified; the administrator needs to know only the cluster name or IP address to add the node to the cluster. Network Load Balancing Manager works well configuring clusters on remote servers but if the cluster is local, NLB Manager will only function correctly if the server has multiple network cards.

To create a cluster, follow these steps:

1.
Log on to the local console of a cluster node using an account with Local Administrator privileges.

2.
Click Start, All Programs, Administrative Tools, Network Load Balancing Manager.

3.
Choose Cluster, New.

4.
Enter the cluster IP address and subnet mask of the new cluster.

5.
Enter the fully qualified domain name for the cluster in the Full Internet Name text box.

6.
Enter the mode of operation (Unicast will meet most of your NLB application deployments).

7.
Configure a remote control password if you will be using the command-line utility NLB.exe to remotely manage the NLB cluster and click Next to continue.

8.
Enter any additional IP addresses that will be load-balanced and click Next to continue.

9.
Configure the appropriate port rules for each IP address in the cluster, being careful to set the correct affinity for the load-balanced applications.

10.
After creating all the allowed port rules, you should create disabled port rules to reduce network overhead for the cluster nodes. Be sure to have a port rule for every possible port and click Next on the Port Rules page after all port rules have been created. Figure 31.20 shows a best practice port rule for an NLB Terminal server implementation.

Figure 31.20. Port rule settings for NLB configuration.

11.
On the Connect page, type the name of the server you want to add to the cluster in the Host text box and click Connect.

12.
In the Interface Available window, select the NIC that will host the cluster IP address and click Next to continue.

13.
On the Host Parameters page, set the cluster node priority. Each node requires a unique host priority, and because this is the first node in the cluster, leave the default of 1.

14.
If the node will perform non-clusterrelated network tasks in the same NIC, enter the dedicated IP address and subnet mask. The default is the IP address already bound on the network card.

15.
For nodes that will join the cluster immediately following the cluster creation and after startup, leave the initial host state to Started. When maintenance is necessary, you can change the default state of a particular cluster node to Stopped or Suspended to keep the server from joining the cluster following a reboot.

16.
After you enter all the information on the Host Parameters page, click Finish to create the cluster.

17.
When you're ready to release to the production environment, add the HOST or A record of the new cluster to the DNS domain table. Contact your DNS administrator for information on how to complete this task.

Adding Additional Nodes to an Existing NLB Cluster

When a cluster already exists, administrators can add nodes to it from any server or workstation by using network connectivity, Cluster Administrator permissions, and the Network Load Balancing Manager.

To add nodes to an existing cluster, perform the following steps:

1.
Log on to a workstation or server that has the Windows Server 2003 Administrative Tools installed.

2.
Click Start, All Programs, Administrative Tools and right-click Network Load Balancing Manager.

3.
Choose the Run-as option and specify an account that has Administrative permissions on the cluster.

4.
Choose Cluster, Connect to Existing.

5.
In the Host text box, type the IP address or name of the cluster and click Connect.

6.
From the Clusters window, select the cluster you want to connect to and click Finish to connect.

7.
In the right pane, right-click the cluster name and choose Add Host to Cluster, as shown in Figure 31.21.

Figure 31.21. Choosing to add a host to the cluster.

[View full size image]

8.
On the Connect page, type the name of the server you want to add to the cluster in the Host text box and click Connect.

9.
In the Interface Available window, select the NIC that will host the cluster IP address and click Next to continue.

10.
On the Host Parameters page, set the cluster node priority. Each node requires a unique host priority, and because this is the first node in the cluster, leave the default of 1.

11.
If the node will perform non-clusterrelated network tasks in the same NIC, enter the dedicated IP address and subnet mask. The default is the IP address already bound on the network card.

12.
For nodes that will join the cluster immediately following the cluster creation and after startup, leave the initial host state to Started. When maintenance is necessary, you can change the default state of a particular cluster node to Stopped or Suspended to keep the server from joining the cluster following a reboot.

13.
After you enter all the information in the Host Parameters page, click Finish to add the node to the cluster.


Managing NLB Clusters

A cluster can be managed using the NLB Manager or the NLB.exe command-line utility. Using the NLB Manager, a node can be added, removed, or suspended from cluster operation to perform maintenance, including hardware or software updates. Because data is not replicated between cluster nodes, any data needs to be replicated manually or by using tools such as Robocopy.exe, which are located in the Windows Server 2003 Resource Kit.

Note

Network activity for NLB clusters can be monitored using the Network Monitor and parsers provided in the Windows Server 2003 Resource Kit. These parsers are called Wlbs_hb.dll and wlbs_rc.dll.

Backing Up and Restoring NLB Nodes

The procedure for backing up and restoring NLB nodes is no different than for standalone servers. An ASR backup should be created after any major server configuration change, and the local disks and system state of each node should be backed up regularly (weekly). An NLB configuration can be restored when the system state of a particular node is restored. If a full node recovery is necessary, the system state and local disks should be restored or an ASR restore should be performed. For detailed backup and restore procedures, refer to Chapters 32 and 33 and follow procedures for backing up and restoring standalone servers.

Performing Maintenance on a Cluster Node

To perform maintenance on an NLB cluster node, the administrator can temporarily remove the node from the cluster, perform the upgrade, and add it back in later. Removing the node from the cluster without affecting user connections requires the use of the drainstop option from the Network Load Balancing Manager. The drainstop option tells the cluster to take this node offline and immediately stop connecting new clients to this node. Existing sessions will remain active until they are all closed. When all the sessions are complete, maintenance can be performed, and the server can be made available in the cluster to start accepting user requests.

To perform maintenance on a cluster node, follow these steps:

1.
Log on to a workstation or server that has the Windows Server 2003 Administrative Tools installed.

2.
Click Start, All Programs, Administrative Tools and right-click Network Load Balancing Manager.

3.
Choose the Run-as option and specify an account that has Administrative permissions on the cluster.

4.
Choose Cluster, Connect to Existing.

5.
In the Host text box, type the IP address or name of the cluster and click Connect.

6.
From the Clusters window, select the cluster you want to connect to and click Finish to connect.

7.
Each node in the cluster should appear with a green background, signifying operational status. Right-click the node to perform maintenance and select Control Host, Drainstop, as shown in Figure 31.22.

Figure 31.22. Selecting the Control Host, Drainstop option.

[View full size image]

8.
When the node is draining, it should have a half-red and half-green background, and the drainstop operation result should be listed in the log window. Right-click the draining cluster node and select Host Status.

9.
Refer to the summary status to verify that the node is draining and then click OK to close this window.

10.
After you complete all connections on this node, the node will turn red. Perform any necessary maintenance.

11.
When maintenance is complete, if no reboots are necessary, in the NLB Manager, right-click the node and choose Start. If a reboot is necessary, the node will rejoin the cluster according to Initial Host State settings on the Host property page. Change the Initial Host State settings as necessary to achieve the desired node effect according to the type of maintenance that is being performed.

12.
When the node completes rejoining the cluster, it should have a green background in the NLB Manager window.

13.
Click File, Close to exit the Network Load Balancing Manager utility.

Removing a Node from an NLB Cluster

To remove an existing node from a cluster, follow the steps up to step 10 in the "Performing Maintenance on a Cluster Node" section. Then do the following:

1. | Right-click the node and choose Delete Host.
2. | A warning message pops up stating that this action will remove the node from the cluster. Click the Yes button to remove the node.

Deleting the Entire Cluster

To delete an entire cluster, follow the procedure in the "Performing Maintenance on a Cluster Node" section on each node in the cluster. When all nodes are red, indicating a stopped status, right-click the cluster name and choose Delete Cluster, as shown in Figure 31.23.

Figure 31.23. Deleting a cluster.

[View full size image]


Summary

Windows Server 2003 clustering services enable organizations to create system-level fault tolerance and provide high availability for mission-critical applications and services. Although Cluster Service and network load balancing are each characteristically different and are best deployed on very different types of applications, between them they can increase fault tolerance for almost any application.


Best Practices

  • Purchase quality server and network hardware to build a fault-tolerant system. The proper configuration of this hardware is equally important.

  • Create disk subsystem redundancy using RAID.

  • Don't attempt to run both MSCS and NLB on the same computer because Microsoft does not support them due to potential hardware-sharing conflicts.

  • Use cluster-aware applications so that the cluster service can monitor the application. A cluster-unaware application can run on a cluster, but the application itself it not monitored by Cluster Service.

  • Use active/passive clustering mode except in cases where performance is critical. Active/passive mode is easier to manage and maintain, and the licensing costs are generally lower.

  • Use NLB to provide connectivity to TCP/IP-based services such as Terminal services, Web sites, VPN services, and streaming media services.

  • Use Windows Server 2003 Cluster Services to provide server failover functionality for mission-critical applications such as enterprise messaging, databases, and file and print services.

  • Disable power management on each of the cluster nodes both in the motherboard BIOS and in the Power applet in the operating system's Control Panel to avoid unwanted failover.

  • Carefully choose whether to use a shared disk or a nonshared approach to clustering.

  • Always purchase one additional node when planning for an MNS cluster.

  • Be sure that both Microsoft and the software manufacturer certify that third-party software packages for Cluster Service will work on a Windows Server 2003 cluster; otherwise, support will be limited when troubleshooting is necessary.

  • Use multiple network cards in each node so that one card can be dedicated to internal cluster communication (private network) while the other can be used only for client connectivity (public network) or for both public and private communication (mixed network).

  • Configure the failback schedule to allow failback only during non-peak times or after hours to reduce the chance of having a group failing back to a node during regular business hours after a failure.

  • Thoroughly test failover and failback mechanisms.

  • Do not change the Cluster Service account password using the Active Directory Users and Computers snap-in or the Windows security box if logged in with that account.

  • Be sure that a majority of the nodes remain running to keep the cluster in a working state if you're removing a node from an MNS cluster.

  • Carefully consider backing up and restoring a cluster.

  • Perform ASR backups periodically and immediately following any hardware changes to a cluster node including changes on a shared storage device or local disk configuration.

  • Thoroughly understand the application that will be used before determining which clustering technology to use.

  • Create a port rule that allows only specific ports to the clustered IP address and an additional rule blocking all other ports and ranges.

  • Employ tools such as Robocopy.exe, which are located in the Windows Server 2003 resource kit or Application Center, to replicate data between NLB nodes.


Chapter 32. Backing Up a Windows Server 2003 Environment

In This Chapter

  • Disaster Recovery Planning

  • Discovery: Learning the Environment

  • Documenting the Enterprise

  • Developing a Backup Strategy

  • Backing Up the Windows Server 2003 Operating System and Services

  • Examining the Windows Server 2003 Backup Programs

  • Virtual Disk Service

  • Using the Windows Server 2003 Backup Utility (ntbackup.exe)

  • Using Remote Storage

  • Using the Volume Shadow Copy Service

  • Windows Server 2003 Service Backup Options

  • Media Management for Windows Server 2003 Backup and the Remote Storage Service

  • Windows Server 2003 Startup Troubleshooting Utilities

Windows Server 2003 is a robust and reliable operating system platform. There are many reasons to introduce Windows Server 2003 systems into a server environment, including distributed file, remote access, directory, print, Web, and network services. This stable platform can support several users, but as with any production implementation of a server, before the product is deployed, IT personnel should know how to install and configure it properly, how to optimize and monitor performance, how to support it, and equally important, how to back up and restore if a system failure is encountered.

When a new computer service, application, or operating system platform is introduced into a network, it always requires attention in the area of backup and disaster recovery planning. Administrators are faced with the task of creating a disaster recovery plan, which can seem to be an intimidating task. Disaster recovery planning is analogous to the age-old question, "What came first: the chicken or the egg?" How does it compare? For a disaster recovery plan, the question may be "What comes first: the backup plan or the recovery plan?" At least in this case, the answer is simple: They complement one another, so they should be planned in parallel.

Before a backup plan can be created, administrators must understand what types of failures or disasters they need to plan for and the recovery requirements for each of these failures. Learning first what is necessary for a recovery gives administrators a list of all the elements they may need to back up for recovery when a particular failure is encountered. When they know what needs to be backed up, they can then create the backup plan. So it is recommended that administrators research each server service and application to understand what is necessary for recovery so that their backup plan will target the correct information.

This chapter covers disaster recovery planning, providing tips, tricks, and best practices on implementing a backup and recovery strategy. In addition, it also provides step-by-step instructions for using tools built into Windows Server 2003.


Disaster Recovery Planning

Disaster recovery planning is an important part of any organization's business operations. Disaster recovery planning is not just for servers, but is for the entire company. Not only does the organization need a plan to recover the server, but also the network, including helping the users connect if physical access to an office is unavailable.

Elements of a Disaster

Disasters come in many shapes and forms. This chapter covers backing up Windows Server 2003, but it would not be complete unless we at least outlined all the different areas that should be investigated and addressed when tasked with creating a disaster recovery plan for a computer and networking infrastructure. Knowing what sorts of disasters to plan for is the first step in disaster recovery planning. The following sections describe a few basic disaster types.

Physical Site Disaster

A site disaster is anything that keeps users or customers from reaching their desired office location. Examples include natural disasters such as floods, fires, earthquakes, hurricanes, or tornadoes that can destroy an office. A site disaster also can be a physical limitation, such as a damaged bridge, bomb scare, or building evacuation that would keep the employees from working at their desks. When only physical access is limited or restricted, a remote access solution could re-establish connectivity between users and the corporate network. Refer to Chapter 26, "Remote and Mobile Access," for more information in this area.

Power Outage

Power outages can occur at any time unexpectedly. Some power outages are caused by bad weather and other natural disasters, but other times they can be caused by high power consumption. In the summer of 2001, many businesses located in northern California in the United States were left without power because the power company could not reroute power from the rural areas to the highly utilized areas such as Silicon Valley. Many businesses were unable to function because the core of their work was conducted on computers.

Network Outage

Organizations that use computer networks internally or externally to the Internet are all susceptible to network outages, causing loss of productivity and possibly revenue. Problems include a network line being mistakenly cut, the Internet service provider being purchased or sold, and a new organization inadvertently disconnecting the main connection for the office. Or, a network router or other network equipment, including hubs, switches, network interface cards, or even network cables, can fail.

Server Hardware Failures

Server failures are the type of problem most organizations plan for because they seem to be the most common disaster encountered. Server hardware failures include failed motherboards, processors, memory, network interface cards, disk controllers, power supplies, and, of course, hard disks. Each of these failures can be dealt with differently, but to achieve system-level fault tolerance, a cluster should be implemented using either Windows Server 2003 Cluster Services or network load balancing.

Hard Drive Failure

Hard drives have been singled out as a possible cause of server hardware failure. Windows Server 2003 supports hot-swappable hard drives, but only if the server chassis and disk controllers support such a change. Windows Server 2003 supports two types of disks: basic disks, which provide backward compatibility, and dynamic disks, which allow software-level disk arrays to be configured without a separate hardware-based disk array controller. Also, both basic and dynamic disks, when used as data disks, can be moved to other servers easily to provide data or disk capacity elsewhere if a system hardware failure occurs and the data on these disks needs to be made available as soon as possible.

Note

If hardware-level RAID is configured, the controller card configuration should be backed up using a special vendor utility, or it may need to be re-created from scratch if the disks are moved to a new machine.

Software Corruption

Software corruption can occur at many different levels. There could be software corruption in a file's access control list (ACL), an operating system's file, or an application could have mistakenly overwritten files or folders. Systems providing access to databases are also susceptible to database corruption, so special care should be taken to be sure the databases are frequently backed up and that proper backup and restore techniques are understood.


Discovery: Learning the Environment

Key to creating a disaster recovery plan is understanding the environment that needs the business continuity process defined. While understanding some of the different failures that can occur, administrators must also understand the servers and systems that they plan to back up and be able to document them from top to bottom. This process involves a discovery that includes mapping out both computer technology systems in place as well as business processes used in the organization. While systems can be recovered and replaced, if any changes occur after the recovery, users need training on or communication about such changes. Therefore, the process of learning about the environment involves understanding the technology and the business processes in use in the organization.

Identifying the Different Services and Technologies

Each server service or server/client application on a network provides a key system function vital to or at least desired by the organization. Server applications that require special backup and restore procedures are especially important when disaster recovery planning is necessary. Each application, service, or technology should be identified and documented so the IT group can have a clear view of the complexity of the environment as the plan is being developed.

Identifying Single Points of Failure

A single point of failure is a computer or networking device that provides a particular service exclusively due to application or budget limitations. Every single point of failure should be identified because it is usually a key device such as a very expensive router. Within Windows Server 2003, for instance, Active Directory inherently comes with its own set of single points of failure, with its Flexible Single Master Operations (FSMO) roles. These roles provide an exclusive function to the entire Active Directory forest or just a single domain. For more information on FSMO roles, refer to Chapter 7, "Active Directory Infrastructure."

Prioritizing the Environment

After all the computer services and applications used on a network are identified, including the single points of failure, they should be prioritized by order of most importance. To prioritize services and applications, administrators can start by understanding the purpose or need served by a particular application and how much impact it will have on business productivity or revenue if it becomes unavailable.

For example, a company that sells products via telephone or through a Web site may depend heavily on the database server that stores all the shipments, orders, and inventory; but it may not rely so heavily on the email server, which is used to send out marketing and order confirmation email messages. If, in the former example, the database server became unavailable in the middle of the afternoon, impact on the business could be tremendous because Web site orders would not be available. Phone orders would also suffer because orders may be taken for products that are out of stock. If the email server fails, it would need to be repaired and brought back online, but no loss of revenue would come as a direct result.

Every environment is different, so no single answer can be given when it comes to prioritizing the environment. The best advice is to plan carefully. Only the top few services and applications in the prioritized list will become part of the bare minimum services list.

Identifying Bare Minimum Services

The bare minimum services are the fewest possible services and applications that must be up and running for the business to continue to function. For example, a bare minimum computer service for a retail outlet could be a server that runs the retail software package and manages the register and receipt printer. For an engineering consulting firm, it could be the engineers' workstations and the CAD/CAM applications, the file server that stores the blueprints, and the network plotter.

Creating the Disaster Recovery Solution

When administrators understand what sorts of failures can occur and know which services and applications are most essential, they have gathered almost all the information to create a high-level disaster recovery (D/R) solution. The last piece of the puzzle is finding out what the backup and recovery options are for, if not all the services and applications, at least the bare minimum services. When the process is discovered, the administrators must determine what hardware will be necessary to back up and recover the services locally or remotely if planning for a site disaster. Laying out the different D/R scenarios, only at a high level, and presenting them to the decision makers will allow the staff to view the project from an informed perspective as opposed to thinking of it as just another IT request for additional and unnecessary hardware.

Getting Disaster Recovery Solutions Approved

Prioritizing and identifying the bare minimum services are not only the responsibility of the IT staff; these decisions belong to management as well. The IT staff members are responsible for identifying single points of failure, gathering the statistical information of application and service usage, and possibly also understanding how an outage can affect business operations.

Before the executives can make a decision on how they want to fund the IT department for disaster recovery planning, they should have all the pertinent information to make the most informed decision. When a D/R solution or information is proposed to management, the solution should contain costs associated with additional hardware, complex configurations, and a service-level agreement (SLA) estimating how long it will take to recover the service should a failure occur. Also, different options should be presented to show how different failure scenarios can be accommodated. For example, a spare server with the same specs as a production server can be used to test patches and application updates before they are applied on the production server, thus reducing risks associated with untested updates. This spare server can also be used if a component on the production server fails; the exact component can be swapped out with the spare server, if not the entire server itself.

It is a good idea to present the preferred D/R solution but also a few alternative lower-cost solutions as well. Most likely, the lower-cost solutions will also bring longer downtime intervals, but they may seem reasonable to the executives funding the solution. Getting the budget approved for a secondary D/R plan is better than getting no budget for the preferred plan. The staff should always try to be very clear on the service-level agreements and try to document or have a paper trail concerning D/R solutions that have been accepted or denied. If a failure that could have been planned for occurs but budget was denied, IT staff members or IT managers should make sure to have all their facts straight and documentation to prove it. In the end, regardless of who denied the budget and who chose which failure to plan for, IT staff will always take the blame, so they should push to get the best plan approved.


Documenting the Enterprise

So far, we've discussed what computing services make up the environment, what types of failures to plan for, and which services must be made available first when multiple failures occur or when a site disaster is encountered. Now it is time to start actually building the disaster recovery toolkit that a qualified individual will use to recover a failed service, application, or server. To begin creating the toolkit, the current infrastructure must be documented completely and accurately.

Note

For complete information on documenting the Windows Server 2003 environment, refer to Chapter 24, "Documenting a Windows Server 2003 Environment."

Server Configuration Documentation

Server configuration documentation is essential for any environment regardless of size, number of servers, or disaster recovery budget. A server configuration document contains a server's name, network configuration information, hardware and driver information, disk and volume configuration, or information about the applications installed. A complete server configuration document contains all the necessary configuration information a qualified administrator would need if the server needed to be rebuilt from scratch and the operating system could not be restored from backup. A server configuration document also can be used as a reference when server information needs to be collected.

The Server Build Document

A server build document contains step-by-step instructions on how to build a particular type of server for an organization. The details of this document should be tailored to the skill of the person intended to rebuild the server. For example, if this document was created for disaster recovery purposes, it may be detailed enough that anyone with basic computer skills could rebuild the server. This type of information could also be used to help IT staff follow a particular server build process to ensure that when new servers are added to the network, they all meet company server standards.

Hardware Inventory

Documenting the hardware inventory on an entire network might not always be necessary, but it can be beneficial nonetheless. Many tools are available, such as Microsoft Systems Management Server (SMS), that can assist with hardware inventory by automating much of the process of gathering and recording the necessary information. These tools are especially useful in larger organizations. The amount and type of information the organization collects will vary, and can include every system or device, select network environment components, or specific information such as serial numbers or processor speed.

Network Configurations

Network configuration documentation is essential when network outages occur. Current, accurate network configuration documentation and network diagrams can help simplify and isolate network troubleshooting when a failure occurs.

WAN Connection

WAN connectivity should be documented for enterprise networks that contain many sites to help IT staff understand the enterprise network topology. This document helps the staff figure out how long an update made in Site A will take to reach Site B. This document should contain information about each WAN link, including circuit numbers, ISP contact names, ISP tech support phone numbers, and the network configuration on each end of the connection. It can be used to troubleshoot and isolate WAN connectivity issues.

Router, Switch, and Firewall Configurations

Firewalls, routers, and sometimes switches can run proprietary operating systems with a configuration that is exclusive to the device. Information should be collected from these devices, including logon passwords and current configurations. When a configuration change is planned for any one of these devices, the newly proposed configuration should be created using a text or graphical editor, but the change should be approved before it is made on the production device. Also, a rollback plan should be created first to ensure that the device can be restored to the original state if the change does not deliver the desired results.

Recovery Documentation

Recovery documentation, such as the server build document mentioned previously, can become reasonably complex and focused on a particular task. Recovery documentation aids an administrator in recovering from a failure for a particular server, server platform, specific service, or application. Recovery documentation will be covered in Chapter 33, "Recovering from a Disaster."

Updating Documentation

One of the most important, yet sometimes overlooked, tasks concerning documentation is the updating of documentation. Documentation is tedious, but outdated documentation can be worthless if many changes have occurred since the document was created. For example, if a server configuration document was used to re-create a server from scratch but many changes were applied to the server after the document was created, the correct security patches may not be applied, applications may be configured incorrectly, or data restore attempts could be unsuccessful. Whenever a change will be made to a network device, printer, or server, documentation outlining the previous configuration, proposed changes, and rollback plan should be created before the change is approved and carried out on the production device. After the change is carried out and the device is functioning as desired, the documentation associated with that device or server should be updated.


Developing a Backup Strategy

Developing the backup strategy involves planning the logistics of backing up the necessary information or data either via backup software and media or documentation, but usually it is a combination of both. Other aspects of a backup strategy include assigning specific tasks to individual IT staff members to make sure the best person is making sure that a particular service or server is being backed up regularly and that documentation is accurate and current.

Creating a Master Account List

Creating a master account list is a controversial subject because it contradicts what some security organizations call a best practice; however, many organizations follow this procedure. A master account list contains all the usernames and passwords with root privileges or top-level administrator privileges for network devices, servers, printers, and workstations. This list either should be kept printed in a sealed envelope in a safe at the office or electronically encrypted. This list should be used only when the assigned IT staff members are not available, recovering from a failure is necessary, and only one of the accounts on the list has the necessary access. After the list is used, depending on who needed the temporary access, all the passwords on the list should be changed for security purposes, and another sealed list should be created.

Assigning Tasks and Designating Team Members

Each particular server or network device in the enterprise has specific requirements for backing up and documenting the device and the service it provides. To make sure that a critical system is being backed up properly, IT staff should designate a single individual to monitor that device to ensure the backup is completed and documentation is accurate and current. Assigning a secondary staff member who has the same set of skills to act as a backup if the primary staff member is out sick or unavailable is a wise decision to ensure that there is no single point of failure among IT staff.

Assigning only primary and secondary resources to specific devices or services can help improve the overall security and reliability of the device. By limiting who can back up and restore data, and possibly who can manage the device, to just the primary and secondary qualified staff members, the organization can rest assured that only competent individuals are working on systems they are trained to manage. Even though the backup and restore responsibilities lie with the primary and secondary resources, the backup and recovery plans should still be documented and available to the remaining IT staff.

Creating Regular Backup Procedures

Creating a regular backup procedure helps ensure that the entire enterprise is backed up consistently and properly. When a regular procedure is created, the assigned staff members will soon become accustomed to the procedure, and it will become second nature. If there is no documented procedure, certain items may be overlooked and may not be backed up, which can turn out to be a major problem if a failure occurs. For example, a regular backup procedure for a Windows Server 2003 system could back up the user data on the local drives every night, and perform an Automated System Recovery backup once a month and whenever a hardware change is made to a server.

Creating a Service-Level Agreement for Each Critical Service

An SLA defines the availability and performance of a particular device or service. This is usually linked to a failure. For example, a generic SLA could state that for the file server FP01, if a failure occurs, it can be recovered and available on the network in four hours or less. SLAs are commonly defined specifically within disaster recovery solutions, or sometimes the SLA is the basis for the disaster recovery solution. For example, if a company cannot be without its database for more than one hour, a disaster recovery solution must be created to meet that SLA.

Before an SLA can be defined, the IT staff member responsible for a device must understand what is necessary to recover that device from any type of failure. Also, that person must limit the SLA to only the failure types planned for in the approved disaster recovery solution. For example, say a site outage is not planned for. The SLA may state that, if the device fails, it can be recovered using spare hardware and be back online in two hours or less. On the other hand, if a site failure occurs, there is no estimated recovery time because offsite backup media may need to be collected from an outside storage provider and hardware may need to be purchased or reallocated to re-create the device. The more specific the SLA is, the better the chance of covering every angle.

Determining a Reasonable SLA

An SLA cannot be created until an IT staff member performs test backups and restores to verify that disaster recovery procedures are correct and that the data can be restored in the desired time frame. When an SLA is defined before the disaster recovery solution, the IT staff member needs to see whether a standard recovery procedure will meet the SLA or a creative, sometimes expensive, custom solution may be necessary.

Determining Which Devices Need to Be Backed Up

Each device may have specific backup requirements. The assigned IT staff members are responsible for researching and learning the backup and recovery requirements to ensure that the backup will have everything that is necessary to recover from a device failure. As a rule of thumb for network devices, the device configuration should be backed up, and servers, local and shared storage data, operating system files, and operating system configurations should be backed up. Some backups may simply consist of documentation and a few settings in a text file.

Creating a Windows Server 2003 Boot Floppy

In previous versions of Windows, if RAID 1 volumes were created using the operating system as opposed to a hardware-based RAID volume, the administrator needed to create a specific boot disk to point to the remaining disk to boot the server if the primary disk in the volume failed. Windows Server 2003 removes this dependency because it adds an additional line in the Boot.ini file that points to the second disk's volume, allowing the server to boot properly using the remaining disk. The only caveat is that the administrator needs to select the correct option when the Boot.ini file displays the boot options on the screen. The mirrored volume is referred to as a secondary plex in the following Boot.ini file information:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="C: Windows Server 2003, Enterprise" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Boot Mirror C: - secondary plex"

The preceding example is taken directly from a Boot.ini file from a Windows Server 2003 system using software-level RAID 1 for the system partition. The secondary plex is just a reference, but the disk controller and disk volume information point the boot loader to connect to the correct remaining partition.

Sometimes a boot floppy is necessary, especially if the boot and system volumes are different and the boot files are inaccessible. In a situation like this, a boot floppy is priceless. To create a boot floppy, simply format a floppy disk, and then from the local server console, copy the Boot.ini, NTLDR, and NTDETECT files to the floppy disk. When the BIOS cannot locate the boot loader files, this floppy can be used to boot the system and point the system to the correct volume containing the operating system files.


Backing Up the Windows Server 2003 Operating System and Services

The Windows Server 2003 operating system contains several features to enhance operating system stability, provide data and service redundancy, and deliver feature-rich client services. To provide the most disaster recovery options, many services have their own backup tools and may require additional attention. This section discusses ways to back up a Windows Server 2003 system to prepare for complete server failure or to be able to recover to a previous state. This section also outlines specific Windows Server 2003 services that have tools to aid in the backup recovery process.

Backing Up Boot and System Volumes

A backup strategy for every Windows Server 2003 system should always include the boot and system disk volumes. On many installations, the boot and system volume are one and the same, but sometimes they are located on completely separate volumes, usually on dual-boot computers. For the rest of this section, we will assume that they are both on the same partition, and we will refer to it as the system volume. This volume contains all the files necessary to start the core operating system. It should be backed up before and after a change is made to the operating system and once every 24 hours if possible.

When applications are installed, they will, by default, install on the system partition unless a different partition is specified during installation. On average, the amount of data on the system volume, with applications and services installed, is anywhere from 1GB to 5GB. System volume usage can be on the high end when administrators forget to purge or archive logs such as the Web and FTP logs, if they are used on the system.

Note

When system volumes are backed up, the system state should be backed up at the same time to simplify recovery if a server needs to be rebuilt from scratch.

Backing Up Data Volumes

If a server is used as a file server, it is recommended to store user data separate from the operating system to improve overall system and user data access performance. When systems are built with this recommendation in mind, backing up just the system volume does not back up the user data. Backing up data volumes on a system is just as important, if not more important, than backing up the system volume. This volume usually contains user files and folders and application data including Web site data, log files, and databases. Usually, the data volumes end up being the largest volumes. This makes for longer backup intervals and may require more than one tape if a tape device is being used. For many organizations, a full backup of data volumes can be run only once a week, but to capture all new and modified data, incremental or differential backups can be run every day.

Backing Up Windows Server 2003 Services

Many Windows Server 2003 services store configuration and status data in separate files or databases located in various locations on the system volume. If the service is native to Windows Server 2003, performing a complete server backup on all drives and the system state, the critical data is certainly being backed up. A few services provide alternative backup and restore options. The procedures for backing up these services are outlined in the section titled "Using the Windows Server 2003 Backup Utility (ntbackup.exe)" later in this chapter.

Backing Up the System State

The system state of a Windows Server 2003 system contains, at a minimum, the System Registry, boot files, and the COM+ class registration database. Backing up the system state creates a point-in-time backup that can be used to restore a server to a previous working state. Having a copy of the system state is essential if a server restore is necessary.

How the server is configured determines what else, other than the three items listed previously, will be contained in the system state. On a domain controller, the system state also contains the Active Directory database and the SYSVOL share. On a cluster, it contains the cluster quorum data. When services such as Certificate Server and Internet Information Server, which contain their own service-specific data, are installed, these databases are not listed separately but are backed up with the system state.

Even though the system state contains many subcomponents, using the programs included with Windows Server 2003, the entire system state can be backed up only as a whole. When recovery is necessary, however, there are several different options. Recovering data using a system state backup will be covered in Chapter 33.

The system state should be backed up every night to prepare for several server-related failures. A restore of a system state is very powerful and can return a system to a previous working state if a change needs to be rolled back or if the operating system needs to be restored from scratch after a complete server failure.

Using the Directory Services Restore Mode Password

When a Windows Server 2003 system is promoted to a domain controller, one of the configurations is to create a Directory Restore Services mode password. This password is used only when booting into Directory Restore Services mode. Restore mode is used when the Active Directory database is in need of maintenance or needs to be restored from backup. Many administrators have found themselves without the ability to log in to Restore mode when necessary and have been forced to rebuild systems from scratch to restore the system state data. Many hours can be saved if this password is stored in a safe place, where it can be accessed by the correct administrators.

The Restore mode password is server-specific and created on each domain controller. If the password is forgotten, and the domain controller is still functional, it can be changed using the command-line tool ntdsutil.exe, as shown in Figure 32.1. The example in Figure 32.1 changes the password on the remote domain controller named dc1.companyabc.com.

Figure 32.1. Changing the Active Directory Restore mode password using ntdsutil.exe.

[View full size image]


Examining the Windows Server 2003 Backup Programs

Several utilities included with Windows Server 2003 can be used to back up the operating system and server data. Many environments may choose to provide backups using a combination of these utilities, if not at least one. The Windows Server 2003 Backup utility should be used to back up the entire system. For backing up volume data to disk for added data recovery functionality, the Volume Shadow Copy service can be used. Finally, Remote Storage can be used to manage the data on a volume, which really isn't a backup. The Remote Storage data is stored in a format that can be read by the Windows Server 2003 Backup program, so only the Remote Storage database and the links on the server volume need to be backed up, which can reduce the overall backup time.

Windows Server 2003 Backup Utility (ntbackup.exe)

The Windows Backup utility, ntbackup.exe, has been included with the server and sometimes workstation versions of the operating system for years. This utility can be used to perform a complete backup of the local server, including local drives, shared drives on cluster nodes, servers connecting to an external storage array, and the system state containing all the operating system configurations. The Windows Backup utility is covered in more detail in the "Using the Windows Server 2003 Backup Utility (ntbackup.exe)" section later in this chapter.

ntbackup.exe utilizes the Volume Shadow Copy service to back up opened files and truly create a complete point-in-time system backup. A new feature to the Backup utility is the Automated System Recovery option, which can be used to restore a server from scratch, including re-creating disk volumes. One major limitation of the utility is that it can back up only open files and the system state, and create an ASR backup of the local server.

Remote Storage

The Windows Server 2003 Remote Storage service provides hierarchical storage management for the data stored on volumes. This service can be configured to migrate data from a volume to remote storage media based on when a file was last accessed or when a predetermined free disk space threshold is reached. When a particular file or folder is migrated to remote storage media, the file is replaced with a link called a junction point. When this link is accessed by the system or an end user, the data is migrated from the remote media back to the volume and the file access date is updated.

Remote Storage is not really intended to be a backup solution because the remote storage media can still be the single location of the migrated data; however, if a complete server failure occurs, the data on the remote storage media is recoverable. Windows Server 2003 Backup can be used to read and restore the data on the remote storage media; however, the original location of the data will not be preserved unless the Remote Storage service and database are restored first. For more details on Remote Storage, refer to the "Using Remote Storage" section later in this chapter.

Volume Shadow Copy

The Volume Shadow Copy Service (VSS) is a new service for the Windows Server 2003 operating system, and it can be used to provide two separate backup strategies. The Volume Shadow Copy Service takes a snapshot of a volume, which can be used to restore data from the shadow copy to a volume without having to use a backup program or restore the data from media. This process is relatively fast and is able to back up open files to ensure a complete volume copy. Shadow copies can be enabled on a per-volume basis, and when the Windows Server 2003 Backup utility is used, it can be leveraged to create a volume copy of the drive and then create the backup using the shadow copy instead of accessing the volume directly. This provides faster backups and can improve server performance. The reads on data volumes can be reduced if shadow copies are stored on alternate disks. Volume Shadow Copy can be used only by Windows Server 2003 Backup for local volumes only. More information on the Volume Shadow Copy is provided later in this chapter in the "Using the Volume Shadow Copy Service" section.


Virtual Disk Service

In previous versions of Windows, the operating system had to have special drivers for disk virtualization. Otherwise, it may see storage on a SAN or NAS device that it might not own and consequently try to take over or use the storage when it shouldn't. This created many problems and often required administrators to work closely with third-party disk vendors to implement a storage solution. In Windows Server 2003, the virtual disk service (VDS) provides a management interface that abstracts disk virtualization.

VDS gives administrators more flexibility and control over the disk subsystem. Specifically, external disks used for disk virtualization can be easily managed and maintained just as easily as if the storage were local to the server.

Although VDS is not considered a backup and restore utility, it is a service that administrators have long awaited for backup and recovery purposes. For instance, administrators can more easily allocate and deallocate storage either through a script or the GUI that can be used for storing backup snapshots.

Note

Many organizations are using VDS to create storage volumes for backup snapshots to disk. These snapshots are then backed up to tape during the nightly backup routine. This allows administrators to easily take snapshots periodically during the day to further safeguard data without sacrificing performance or availability.

By default, Windows Server 2003 incorporates basic and dynamic VDS providers, and many VDS providers can be obtained from hardware vendors. These third-party VDS providers supply LUN discovery and management services.


Using the Windows Server 2003 Backup Utility (ntbackup.exe)

Windows Server 2003 includes several tools and services to back up and archive user data, but when it comes to backing up the entire operating system and disk volumes, Windows Server 2003 Backup is the program to use. Windows Server 2003 Backup is included on all the different versions of the platform. Some Windows Server 2003 services provide alternative backup utilities, but they still can be backed up using ntbackup.exe.

Windows Server 2003 Backup provides all the necessary functions to completely back up and restore a single file or the entire Windows Server 2003 system. Third-party, or even other Microsoft, applications installed on a Windows Server 2003 system should be researched to ensure that no special backup requirements or add-ons are necessary to back up the application data and configuration.

Windows Server 2003 Backup has been developed, or limited, to primarily backing up the local server, but it can back up remote server volumes as well. In the case of backing up remote server volumes, open files are skipped, and the system state can be backed up only on the local server.

Modes of Operation

The Windows Backup utility can run in two separate modes: Wizard and Advanced. Wizard mode provides a simple interface that allows a backup to be created in just a few easy steps:

1. | Choose to back up or restore files and settings.
2. | Choose to back up everything or specify what to back up.
3. | Choose what data to back up only if you do not choose the option to back up everything.
4. | Specify the backup media, tape, or file.

That is all it takes to use Wizard mode, but features such as creating a scheduled backup and choosing to disable Volume Shadow Copy can be performed only using Advanced mode.

Advanced mode provides greater granularity when it comes to scheduling and controlling backup media security and other backup options. In the following sections concerning Windows Server 2003 Backup, we will use Advanced mode.

Advanced Mode

Running the Windows Server 2003 Backup utility in Advanced mode enables administrators to configure all the available options for backups. Scheduled backups can be created; specific wizards can be started; and advanced backup options can be configured, such as verifying backup, using volume shadow copies, backing up data in remote storage, and automatically backing up system-protected files.

To create a backup in Advanced mode, perform the following steps:

1.
Click Start, All Programs, Accessories, System Tools, Backup.

2.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink. You can optionally uncheck the Always Start in Wizard Mode option to always start in Advanced mode.

3.
Click the Backup Wizard (Advanced) button to start the Backup Wizard.

4.
Click Next on the Backup Wizard Welcome screen to continue.

5.
On the What to Back Up page, select Back Up Selected Files, Drives, or Network Data and click Next to continue.

6.
On the Items to Back Up page, expand Desktop\My Computer in the left pane and choose each of the local drives and the system state, as shown in Figure 32.2. Then click Next to continue.

Figure 32.2. Selecting items to back up.

7.
Choose your backup media type and choose the correct media tape or file. If you're creating a new file, specify the complete path to the file, and the backup will create the file automatically. Click Next to continue.

8.
If the file you specified resides on a network drive, ensure that there is enough free space to accommodate the backup size.

9.
If you chose tape for the backup, choose the media for the backup and choose to use a new tape.

10.
Click the Advanced button on the Completing the Backup Wizard page to configure advanced options.

11.
Choose the backup type and choose whether to back up migrated remote storage data. The default settings on this page will fit most backups, so click Next to continue.

12.
Choose whether a verify operation will be run on the backup media and click Next. Disabling Volume Shadow Copy would be an option if a backup were just backing up local volumes, not the system state.

13.
Choose the Media Overwrite option of appending or replacing the data on the media and click Next.

14.
On the When to Back Up page, choose to run the backup now or to create a schedule for the backup. If you chose Now, skip to step 18.

15.
If a schedule will be created, enter a job name and click the Set Schedule button.

16.
On the Schedule Job page, select the frequency of the backup, start time, and start date, as shown in Figure 32.3, and click OK when completed. You can set additional configurations using the Settings tab.

Figure 32.3. Creating a schedule for a backup.

17.
On the Set Account Information page, enter the user account name and password that should be used to run the scheduled backup and click OK when completed.

18.
Back on the When to Back Up page, click Next to continue.

19.
Click Finish to save the scheduled backup or immediately start the backup job.

20.
When the backup is complete, review the backup log for detailed information and click Close on the Backup Progress window when finished.

Automated System Recovery

Automated System Recovery is a backup option that is used to back up a system to prepare for a complete server failure. An ASR backup contains disk volume information and a copy of all the data on the boot and system volumes, along with the current system state. ASR can be used to restore a system from scratch, and it will even re-create disk volumes and format them as previously recorded during the ASR backup. ASR does not back up the data stored on volumes that are solely used for data storage.

To perform an ASR backup, an administrator needs a blank floppy disk and a backup device; either a tape device or disk will suffice. One point to keep in mind is that an ASR backup will back up each local drive that contains the operating system and any applications installed. For instance, if the operating system is installed on drive C: and MS Office is installed on drive D:, both of these drives will be completely backed up because the Registry has references to files on the D: drive. Although this can greatly simplify restore procedures, it requires additional storage and increases backup time for an ASR backup. Using a basic installation of Windows Server 2003 Enterprise server with only basic services installed, an ASR backup can average 1.3GB to less than 4GB or 5GB.

ASR backups should be created for a server before and after any hardware changes are performed or when a major configuration change occurs with the system. ASR backups contain disk information including basic or dynamic configuration and volume set type. They save volume or partition data so that when an ASR restore is complete, only the data stored on storage volumes needs to be recovered.

Creating an ASR Backup

An ASR backup can currently be created only from the local server console using the graphic user interface version of the Windows Server 2003 Backup utility.

To create an ASR backup, follow these steps:

1. | Log on to the server using an account that has the right to back up the system. (Any Local Administrator or Domain Administrator has the necessary permissions to complete the operation.)
2. | Click Start, All Programs, Accessories, System Tools, Backup.
3. | If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced mode hyperlink.
4. | Click the Automated System Recovery Wizard button to start the Automated System Recovery Preparation Wizard.
5. | Click Next after reading the Automated System Recovery Preparation Wizard welcome screen.
6. | Choose your backup media type and choose the correct media tape or file. If you're creating a new file, specify the complete path to the file, and the backup will create the file automatically. Click Next to continue.
7. | If you specified a file as the backup media and it resides on a network drive, click OK at the warning message to continue.
8. | If you chose tape for the backup, choose the media for the backup and choose to use a new tape.
9. | Click Finish to complete the Automated System Recovery Preparation Wizard and start the backup.
10. | After the tape or file backup portion completes, the ASR backup prompts you to insert a floppy disk to hold the recovery information. Insert the disk and click OK to continue.
11. | Remove the floppy disk as requested and label the disk with the appropriate ASR backup information. Click OK to continue.
12. | When the ASR backup is complete, click Close on the Backup Progress windows to return to the backup program or click Report to examine the backup report.

Note

The information contained on the ASR floppy disk is also stored on the backup media. The ASR floppy contains only two files, asr.sif and asrpnp.sif, that can be restored from the backup media and copied to a floppy disk if the original ASR floppy cannot be located.

Tips on Using ASR

One way to use ASR to ensure proper operations includes performing an ASR backup after the server is built, updated, configured, and secured. Also, an ASR backup should be performed when hardware configurations change and periodically otherwise. On domain controllers, this period should be less than 60 days to ensure that the domain can be up and running again if an Active Directory authoritative restore is necessary.

ASR backs up only the system and boot partitions. ASR backups, on average, are between 1.3GB to 5GB. To prevent ASR backups from getting too large, user data and file shares should be kept off the system and boot volumes.


Using Remote Storage

As mentioned previously, Remote Storage is a Windows Server 2003 filesystem service that is used to automatically archive data to removable media from a managed NTFS volume. Files are migrated by Remote Storage when they have not been accessed for an extended period of time or when a managed disk drops below an administrator-designated percentage of free disk space. When Remote Storage migrates to a file or folder, that file or folder is replaced on the volume with a file link called a junction point. Junction points take up very little room, which reduces the amount of used disk space but leaves a way for this data to be accessed later in the original location. When a junction point is accessed, it spawns the Remote Storage service to restore the remote storage media back to disk.

Although this service does not provide filesystem fault tolerance, using Remote Storage to manage a volume can improve reliability and recoverability by keeping disk space available and by reducing the amount of data that needs to be backed up or restored when a disk failure occurs. To install and configure the Remote Storage service, refer to Chapter 30, "Filesystem Fault Tolerance."

Remote Storage Media Management

When volumes are backed up using NTBackup or third-party backup software, a best practice is to not back up remote storage data from remote media. Following this practice will result in only a single copy of the migrated data being stored on the remote storage media.

If only a single copy of the media master set is made, the remote storage media data would be lost if a site failure occurred. To prevent this from happening, all remote storage media master sets should be copied once or up to two times for redundancy and offsite storage. To enable remote storage master media set copies, at least two or more drives enabled for Remote Storage must be available.

To set the number of media copies for Remote Storage, follow these steps:

1. | Log on to the server using an account that has the right to back up the system. (Any Local Administrator or Domain Administrator has the necessary permissions to complete the operation.)
2. | Click Start, All Programs, Administrative Tools, Remote Storage.
3. | In the left pane of the console, right-click Remote Storage and select Properties.
4. | Select the Media Copies tab.
5. | Under the Number of Media Copy Sets, choose 0, 1, or 2 to configure the number of copies. Remember that this option will be enabled only if more than one drive for remote storage media is available on the system.
6. | Click OK to save the option, close the Remote Storage console, and log off the server.


Using the Volume Shadow Copy Service

As a new addition to Windows Server 2003, the Volume Shadow Copy Service (VSS) adds the ability to quickly restore data that was deleted from a volume locally or through a network-mapped drive or network file share. Over time, there will be several add-ons to Windows Server 2003 that will extend the functionality of VSS; however, what is built into the operating system already provides a series of data recovery functions. If an organization has available disk capacity, VSS should be enabled as a standard setting for a Client Servicesfocused networking environment.

Configuring Shadow Copies

Enabling shadow copies for a volume can be a simple task. Because shadow copies are created on local disks, shadow copy performance is enhanced if a volume's shadow copy is written to a separate disk. This way, each disk mostly performs either a read or write operation, but not both. The Volume Shadow Copy Service is already installed and is automatically available on NTFS-formatted volumes.

To enable and configure shadow copies, follow these steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Click Start, All Programs, Administrative Tools, Computer Management.
3. | In the left pane, if it is not already expanded, double-click Computer Management (local).
4. | Click the plus sign next to Storage.
5. | Select Disk Management.
6. | Right-click Disk Management, select All Tasks, and click Configure Shadow Copies.
7. | On the Shadow Copies page, select a single volume for which you want to enable shadow copies and click Settings.
8. | The Settings page allows you to choose an alternate volume to store the shadow copies. Select the desired volume for the shadow copy.
9. | Configure the maximum amount of disk space that will be allocated to shadow copies.
10. | The default schedule for shadow copies is twice a day at 7:00 a.m. and 12:00 p.m. If this does not meet your business requirements, click the Schedule button and configure a custom schedule.
11. | Click OK to enable shadow copies on that volume and return to the Shadow Copies page.
12. | If necessary, select the next volume and enable shadow copying; otherwise, select the enabled volume and immediately create a shadow copy by clicking the Create Now button.
13. | If necessary, select the next volume and immediately create a shadow copy by clicking the Create Now button.
14. | After the shadow copies are created, click OK to close the Shadow Copies page, close the Computer Management console, and log off the server.

Volume Shadow Copy Best Practices

If volume shadow copies will be enabled on a volume, a few best practices and maintenance tasks should be followed. An appropriate size limit should be set for the shadow copies. Volumes that have many files changed daily should have larger limits than volumes whose data does not change very often. Also, shadow copies should be scheduled to run more often on heavily used drivesat least twice a day. Shadow copies should be stored on separate volumes if possible. This gives an administrator better performance backing up and restoring data to and from shadow copies. Lastly, the number of stored volume shadow copies should be monitored to keep management simple.

Limitations

The Volume Shadow Copy service should not be considered a tool for backing up and restoring servers to previous states. The Windows Server 2003 Backup utility should be used to back up the system volume and system state. Volume Shadow Copy works well for data volumes, and that is what Volume Shadow Copy backups should be focused toward. For system drives, Volume Shadow Copy may be used to restore some of the files on the system to a previous state, but Windows File Protection does a reasonably good job of protecting operating system files without volume shadow copies.

Shadow Copy Management Using vssadmin.exe

The command-line tool vssadmin.exe can be used to enable shadow copies on a volume. This tool can be used to configure most of the configuration settings, including deleting previous shadow copies. Combining vssadmin.exe with a scheduled task and a batch file, shadow copy management can be somewhat automated. For example, vssadmin.exe commands can be added to a batch script and configured to delete the oldest shadow copy on a volume at 12:00 p.m. every day.

To use vssadmin.exe to delete the oldest shadow copy on a volume, perform the following steps:

1. | Log on to the desired server using an account with Local Administrator access.
2. | Click Start, Run.
3. | Type cmd.exe and click OK to open a command prompt.
4. | Type vssadmin.exe delete shadows /For=C: /Oldest /Quiet and then press Enter to delete the oldest shadow copy for the C volume.
5. | Type exit and press Enter to close the command prompt and log off the server.

To schedule this operation, create a text document using Notepad, type the command in step 4, and then press Enter. Save the file with a .bat or .cmd extension. Finally, open the Control Panel, select Scheduled Tasks, and create a new task to execute this file during the desired schedule.


Windows Server 2003 Service Backup Options

Most Windows Server 2003 services that contain a database or local files are backed up with the system state but also provide alternate backup and restore options. Because the system state restore is usually an all-or-nothing proposition except when it comes to cluster nodes and domain controllers, restoring an entire system state may deliver undesired results if only a specific service database restore is required. This section outlines services that either have separate backup/restore utilities or require special attention to ensure a successful backup.

Disk Configuration (Software RAID Sets)

Disk configuration is not a service but should be backed up to ensure that proper partition assignments can be restored. When dynamic disks are used to create complex volumes such as mirrored, striped, spanned, or RAID 5 volumes, the disk configuration should be saved. This way, if the operating system is corrupted and needs to be rebuilt from scratch, the complex volumes will need to have only their configuration restored, which could greatly reduce the recovery time. Only an automated system recovery backup can back up disk and volume configuration.

Certificate Services

Installing Certificate Services creates a Certificate Authority (CA) on the Windows Server 2003 system. The CA is used to manage and allocate certificates to users, servers, and workstations when files, folders, email, or network communication needs to be secured or encrypted.

When the CA allocates a certificate to a machine or user, that information is recorded in the certificate database on the local drive of the CA. If this database is corrupted or deleted, all certificates allocated from this server become invalid or unusable. To avoid this problem, the certificates and Certificate Services database should be backed up frequently. Even if certificates are rarely allocated to new users or machines, backups should still be performed regularly.

Certificate Services can be backed up in three ways: by backing up the CA server's system state, using the Certificate Authority Microsoft Management Console (MMC) snap-in, or using the command-line utility Certutil.exe. Backing up Certificate Services by backing up the system state is the preferred method because it can be easily automated and scheduled. But using the graphic console or command-line utility adds the benefit of being able to restore Certificate Services to a previous state without restoring the entire server system state or taking down the entire server for the restore.

To create a backup of the Certificate Authority using the graphic console, follow these steps:

1.
Log on to the Certificate Authority server using an account with Local Administrator rights.

2.
Open Windows Explorer and create a folder named CaBackup on the C: drive.

3.
Click Start, All Programs, Administrative Tools, Certification Authority.

4.
Expand the Certificate Authority icon and select the desired CA server.

5.
From the console window, select the Action pulldown menu and select All Tasks, BackUp CA.

6.
Click Next on the Certification Authority Backup Wizard Welcome screen.

7.
On the Items to Back Up page, check the Private Key and CA Certificate box and the Certificate Database and Certificate Database Log box, as shown in Figure 32.4.

Figure 32.4. Selecting items for the Certificate Authority backup.

8.
Specify the location to store the CA backup files. Use the folder created in the beginning of this process. Click Next to continue.

9.
When the CA certificate and private key are backed up, this data file must be protected with a password. Enter a password for this file, confirm it, and click Next to continue.

Note

To restore the CA private key and CA certificate, you must use the password entered in step 9. Store this password in a safe place, possibly with the Master account list.

10.
Click Finish to create the CA backup.

Domain Name Service

Domain Name Service (DNS) configuration data is stored in the Registry and is backed up with the system state backup. For each DNS zone that is hosted on the Windows Server 2003 system, a backup zone file is created and stored in the %systemroot%\DNS\Backup folder. These files can be backed up and used to restore a DNS zone to the same server after a restore or to a completely different server. For information on how to create a DNS zone from an existing file, refer to Chapter 33 on restoring DNS data.

Note

Active Directoryintegrated zones will not have a valid backup file in the DNS/backup folder. To back up an Active Directory-integrated zone, perform a system state backup on any AD domain controller running DNS and hosting the zone.

Windows Internet Naming Service

Windows Internet Naming Service (WINS) is a database composed of NetBIOS names and their corresponding IP addresses. The NetBIOS names include domain, server, and workstation names, along with other records used to identify services such as the master browser. The WINS database is backed up by performing a system state backup of the WINS server or by initiating a backup using the WINS console.

Because the WINS database is populated by servers and workstations dynamically, in some cases backing up may not be necessary. When WINS contains several static mappings, a WINS backup is essential because records will not be re-created automatically if the WINS database is corrupted or rebuilt from scratch. Also, even if only dynamic records populate the database, each device registers with WINS only on startup and then periodically, so the record may not be re-created in time. This results in NetBIOS-dependent clients failing to locate the proper server or workstation.

To create a backup using the WINS console, perform the following steps:

1.
Log on to the WINS server using an account with Local Administrator access.

2.
Click Start, All Programs, Administrative Tools, WINS.

3.
If the local WINS server does not appear in the window, right-click WINS in the left pane and select Add Server.

4.
Type in the NetBIOS or fully qualified domain name of the WINS server and click OK.

5.
Select the WINS server in the left pane.

6.
Right-click the WINS server and select Properties.

7.
In the lower section of the General tab, type in the path where the WINS backup should be stored. Check the box to enable WINS database backup during server shutdown, as shown in Figure 32.5.

Figure 32.5. Configuring WINS backup options.

8.
Click OK to close the WINS server property pages.

9.
Right-click the WINS server in the left pane and select Back Up Database.

10.
When the Browse for Folder window opens, select the appropriate folder to back up the WINS database and click OK to perform the backup.

11.
A pop-up window appears stating whether the backup was successful. If it was, click OK, close the WINS console, and log off the WINS server.

12.
If the backup failed, check Permissions in the specified directory to ensure that the logged-on user and system account have at least Modify privileges. Then attempt the backup again.

Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) server is responsible for assigning IP addresses and options to devices on the network in need of network configuration. DHCP allocates IP configurations, including IP addresses, subnet masks, default gateways, DNS servers, WINS servers, and for RIS servers, TFTP servers and boot filenames. Other IP options can be configured, depending on the organization's needs.

These IP address scope properties and options are stored in the DHCP database. This database also stores the information concerning IP address leases and reservations. The DHCP database is backed up with a server system state backup, but it can also be backed up using the DHCP console.

To back up the DHCP database from the console, follow these steps:

1. | Log on to the DHCP server using an account with Local Administrator access.
2. | Click Start, All Programs, Administrative Tools, DHCP.
3. | If the local DHCP server does not appear in the window, right-click DHCP in the left pane and select Add Server.
4. | Type in the fully qualified domain name for the DHCP server and click OK.
5. | Right-click the DHCP server in the left pane and select Properties.
6. | Select the Advanced tab.
7. | In the Backup Path field, the default location for the DHCP database is already populated. If this location is acceptable, click OK. If it is not the correct location, type in or browse for the appropriate backup folder.
8. | Right-click the DHCP server in the left pane and choose Backup.
9. | Select the folder specified in the DHCP Backup Location field in the DHCP Server Advanced property page.
10. | When the backup is complete, no confirmation pop-up window will appear. If it fails, an error will be displayed. Close the DHCP console and log off the server.

Distributed File System

The Distributed File System (DFS) is a Windows Server 2003 service that improves file share availability by providing a single unified namespace to access shared folders hosted across different servers. When domain DFS roots are used, DFS targets can be configured to replicate with one another using the File Replication Service. Domain DFS stores the DFS root, link, target, and replication information in Active Directory. When a standalone DFS root is used, the configuration is stored in the DFS root server's Registry. Backing up the system state of a standalone DFS root server backs up the DFS configuration. For domain DFS roots, backing up the system state of a domain controller accomplishes this task. More information on DFS can be found in Chapter 30.

A command-line utility called Dfscmd.exe can be used to list standalone or domain DFS root information, including root targets, links, and link targets. This information can be saved to a file and be used to restore this information if the DFS configuration is lost. This utility does not list, record, or re-create replication connections for domain DFS roots and targets that are configured for replication.

To create a file containing DFS root configurations, perform the following steps:

1. | Log on to either the standalone DFS root server or a server in the domain using an account with privileges to create domain DFS roots and links.
2. | Click Start, Run and then type cmd.exe. Press Enter when you're done to open the command prompt.
3. | To create a file containing all the root and link targets associated with a domain DFS root called \\Companyabc.com\Apps, type Dfscmd.exe /View \\Companyabc.com\Apps /Batchrestore > DFSrestore.bat and press Enter. This will create a file that can be used to restore additional root targets and create links and link targets when the initial DFS root target is re-created.

Note

Dfscmd.exe is a great tool because it can be used to back up DFS configuration information, but it cannot create the initial DFS root target, nor can it copy replication information for domain DFS targets that are configured for replication. To back up domain DFS completely, perform a backup of the Active Directory database by backing up the system state of a domain controller in the appropriate domain.

Internet Information Services

Internet Information Services (IIS) is Windows Server 2003's Web and FTP server. It is included on every version of the Windows Server 2003 platform but is not installed by default. IIS stores configuration information for Web and FTP site configurations and security in the IIS metabase. The IIS metabase can be backed up by performing a system state backup of the server running IIS, but it can also be backed up using the IIS console. The IIS metabase should be backed up separately before and after an IIS configuration change is made to ensure a successful rollback and to have the latest IIS configuration data backed up after the update.

To back up the IIS metabase using the IIS console, perform the following steps:

1.
Log on to the IIS server using an account with Local Administrator access.

2.
Click Start, All Programs, Administrative Tools, Internet Information Services (IIS) Manager.

3.
If the local IIS server does not appear in the window, right-click Internet Information Services in the left pane and select Connect.

4.
Type in the fully qualified domain name for the IIS server and click OK.

5.
Right-click the IIS server in the left pane and select All Tasks, Backup/Restore Configuration.

6.
The Configuration Backup/Restore window lists all the automatic IIS backups that have been created. Click the Create Backup button.

7.
Enter the backup name and, if necessary, check the Encrypt Backup Using Password box. Enter and confirm the password, and click OK when you're finished, as shown in Figure 32.6.

Figure 32.6. Creating an IIS configuration backup.

8.
When the backup is complete, it is listed in the Configuration Backup/Restore window. Click Close to return to the IIS console.

Before a change is made to the IIS configuration, a backup should be manually created first. When the change is completed, the administrator should either perform another backup or choose the option to save the configuration to disk. The administrator can save new IIS configuration changes to disk by right-clicking the IIS server, selecting All Tasks, and then choosing Save Configuration to Disk. This option works correctly only after a change has been made that has not yet been recorded in the IIS metabase.

Backing Up the Remote Storage Service

The Remote Storage service keeps track of managed volume configurations and migrated data using the Remote Storage database. To back up the Remote Storage database, the administrator needs to back up the information in the system state.

If the Remote Storage service is installed, the administrator can back up the data associated with the remote storage media and migrated data by simply backing up the data contained in the following directories:

%systemroot%\System32\Ntmsdata
%systemroot%\System32\Remotestorage

If the Remote Storage service is running, the data in the Remote Storage folder cannot be backed up unless the system state is backed up.

Note

The Remote Storage database is backed up only when the system state is backed up using an account with Administrative access on the server.

Backing Up the Removable Storage Service

The two services Remote Storage and Removable Storage sound similar and sometimes are mixed up with one another. The Remote Storage service is used to manage a volume. The Removable Storage service is used to manage removable media, such as tapes and optical media.

To back up the Removable Storage media information, back up the following directory:

%systemroot%\System32\Ntmsdata


Media Management for Windows Server 2003 Backup and the Remote Storage Service

Remote Storage and Windows Server 2003 Backup use the Removable Storage service to allocate and deallocate media. The media can be managed using the Removable Storage console in the Computer Management Administrative Tools. The Removable Storage service allocates and deallocates media for these services by allowing each service to access media in media sets created for the respective program.

Media Pools

The Windows Server 2003 Removable Storage service organizes media within media pools so that policies and permissions can be applied and different functions can be performed. For example, the backup media pool is allocated for media created using Windows Server 2003 Backup. Only users granted the privilege to back up or restore the system, or administer the removable media service, have access to this media pool.

Free Pool

The free pool contains media that can be used by any backup or archiving software that utilizes the Windows Server 2003 Removable Storage service. Media in this pool are usually blank media or media marked as clean, and can be overwritten and reallocated.

Remote Storage Pool

The remote storage pool is used on a server only if the Remote Storage server has been installed. This pool stores media allocated for the Remote Storage service. If no tape is found, the device reallocates media from the free pool.

Imported Pool

When media are inserted into a tape device and inventory is run, if the media are not blank and not already allocated to the remote storage pool or backup media pool, they are stored in the imported media pool. If the media are known to have been created with Windows Server 2003 Backup, opening the backup program and performing a catalog should be sufficient to reallocate this media to the backup pool set.

Backup Pool

The backup pool contains all the media allocated to the Windows Server 2003 Backup program.

Custom Media Pools

Custom media pools can be created if special removable media options are required. Media pool options are very limited in Windows Server 2003, and there should be no compelling reason to create a custom media pool.


Windows Server 2003 Startup Troubleshooting Utilities

When a Windows Server 2003 system has startup issues, a few different startup options can be used to troubleshoot the problem. On every server, when the boot loader is shown, the administrator can choose to start the server in Safe mode. This can be a command-prompt window or a graphical interface that can be used to disable a driver or reconfigure a software setting. Other options include enabling Windows to boot up into a recovery console or using a new service called Emergency Management Services. Each of the services or startup options just mentioned does not back up the server but may require previous configuration information to make its services available when recovery is necessary.

Recovery Console

The Recovery Console provides an alternative bootup method when Safe mode and normal boot does not work. The Recovery Console can be installed after the operating system has already been loaded, or it can be called while booting a system from the Windows Server 2003 setup CD.

To install the Recovery Console on an existing system, follow these steps:

1.
Log on to the desired server using an account with Local Administrator access.

2.
Insert the Windows Server 2003 CD in the local CD-ROM drive.

3.
Type cmd.exe in the Start, Run dialog box and click OK to open a command prompt.

4.
Change the drive focus in the command prompt to the drive letter of the CD-ROM drive.

5.
Change the directory to the I386 directory.

6.
Type winnt32.exe /cmdcons and press Enter. This command will start the Recovery Console setup, as shown in Figure 32.7.

Figure 32.7. Installing the Recovery Console.

7.
Click Yes to begin the installation of the Recovery Console. After the installation is finished, click OK. When the installation is complete, the boot.ini file will contain an option to boot into the Recovery Console when the system is starting up.

Emergency Management Services Console Redirection

Windows Server 2003 enables administrators to remotely manage or troubleshoot a system when normal operating system functionality is not available. Using out-of-band connections, such as a serial COM port, information can be redirected to other servers to resolve startup or operating system problems. Emergency Management Services can be used when physical access to a server is not available, and remote administrative options through network connections are not working properly.

Some hardware requirements must be met before Emergency Management Services console redirection can be used. For example, the system motherboard BIOS must support Serial Port Console Redirection (SPCR). Emergency Management Services is enabled and installed on servers during operating system installation if the motherboard supports SPCR. Refer to the Windows Server 2003 Help and Support for overview information.


Summary

When it comes to disaster recovery planning and backing up a Windows Server 2003 system, there are many issues to consider. Specialized utilities can be leveraged for specific backup tasks, but for complete server backup, the command-line utility ntbackup.exe can take care of most of the Windows Server 2003 backup requirements.


Best Practices

  • Make sure that disaster recovery planning includes considerations for the physical site, power, entire system failure, server component failure, and software corruption.

  • Identify the different services and technologies, points of failure, and critical areas; then prioritize in order of importance.

  • Make sure that the D/R solution contains costs associated with additional hardware, complex configurations, and a service-level agreement estimating how long it will take to recover the service should a failure occur. Different options should also be presented.

  • Document the server configuration for any environment regardless of size, number of servers, or disaster recovery budget.

  • Back up system volumes and the system state at the same time to simplify recovery if a server needs to be rebuilt from scratch.

  • Perform an ASR backup after the server is built, updated, configured, and secured. Also, perform an ASR backup when hardware configurations change and periodically otherwise.

  • Perform an ASR backup on domain controllers every 60 days to ensure that if an Active Directory authoritative restore is necessary, you can get the domain up and running again.

  • Set an appropriate size limit for the shadow copies. Volumes that have many files changed daily should have larger limits than volumes whose data does not change very often.

  • Schedule shadow copies to run more often on heavily used drives, at least twice a day.

  • Keep the number of stored volume shadow copies to a minimum to keep management simple.

  • Don't restore Active Directoryintegrated zones using a backup file. Instead, the zones should be created empty and the domain controller should re-create the records.

  • Ensure that the Remote Storage database will be backed up by backing up the system state.


Chapter 33. Recovering from a Disaster

In This Chapter

  • Validating Backup Data and Procedures

  • Isolating Failures

  • Site Failure Recovery

  • Recovering from a Disk Failure

  • Resolving Boot Failure Problems

  • Recovering from a Complete Server Failure

  • Resolving Windows Server 2003 Networking Services Errors

  • Re-creating Windows Server 2003 File Services and Data

  • Restoring Internet Information Services

  • Re-establishing the Cluster Service

  • Resolving Windows Server 2003 Domain Controller Failure

  • Restoring Active Directory

  • Recovering the Removable Storage Database

  • Restoring Remote Storage Database

  • Achieving 99.999% Uptime Using Windows Server 2003

During a failure or after a disaster, many organizations figure out that their disaster recovery plans could have been bettera lot better. Organizations not only should plan for different types of failures and disasters, but they also should periodically simulate a failure to ensure that the plans are correct, up-to-date, and complete. If the appropriate level of disaster planning has been performed, as outlined in Chapter 32, "Backing Up a Windows Server 2003 Environment," organizations can recover from Windows Server 2003 failures. This chapter offers the recommended and practical approach to recovery.


Validating Backup Data and Procedures

This chapter is intended as a follow-up to Chapter 32, which describes backing up in the Windows Server 2003 environment. However, if you're reading this chapter to recover from a failure, skip this section and move on to "Isolating Failures" later in this chapter.

After backup strategies are developed for Windows Server 2003 systems, the backup/restore procedures need to be tested to ensure that the documentation is up to date and accurate. Many organizations outsource document creation to consulting firms that create the plan based on their experience with the product and their limited exposure to the organization's environment. This is why just having the plan often is not good enough. Also, when configurations change, someone should have an electronic, writable copy available and understand how to update the document. For detailed information on Windows Server 2003 documentation, refer to Chapter 24, "Documenting a Windows Server 2003 Environment."

Documenting the Recovery

One important aspect of recovery feasibility is knowing how to recover from a disaster. Just knowing what to back up and what scenarios to plan for is not enough. Restore processes should be created and tested to ensure that a restore can meet service-level agreements (SLAs) and that the staff members understand all the necessary steps.

When a process is figured out, it should be documented, and the documentation should be written to make sense to the desired audience. For example, if a failure occurs in a satellite office that has only marketing employees and one of them is forced to recover a server, the documentation needs to be written so that it can be understood by just about anyone. If the IT staff will be performing the restore, the documentation can be less detailed, but assume a certain level of knowledge and expertise with the server product. The first paragraph of any document related to backup and recovery should be a summary of what the document is used for and the level of skill necessary to perform the task and understand the document.

Including Test Restores in the Scheduled Maintenance

One of the key elements to having a successful disaster recovery plan is to periodically test the restore procedures to verify accuracy and to test the backup media to ensure that data can actually be recovered. Most organizations or administrators assume that, if the backup software reports "Successful," the backup is good and data can be recovered. If a special backup consideration is not taken care of, but the files are backed up, the successful backup may not contain everything necessary to restore a server if data loss or software corruption occurs.

Restores of not only file data, but also application data and configurations should be performed as part of a regular maintenance schedule to ensure that the backup method is correct and disaster recovery procedures and documentation are current. Such tests also should verify that the backup media can be read from and used to restore data. Adding periodic test restores to regular maintenance intervals ensures that backups are successful and familiarizes the administrators with the procedures necessary to recover so that when a real disaster occurs, the recovery can be performed correctly and efficiently the first time.


Isolating Failures

When monitoring software or users report failures or send alerts, the administrator should start troubleshooting by validating that the failure really exists. To do this, the administrator needs a test workstation and test user account and also needs to understand how the particular application or service works.

Using a Test Workstation

To test a reported problem, the administrator should use a test workstation. This workstation should be configured to match an end user's workstation so that tests yield the same results the end user received. User applications should be installed on this workstation with the same settings and permissions. An alternative to having a test workstation is to use remote control software such as Remote Assistance to connect directly to the user's workstation and witness the reported issue firsthand.

Configuring a Test User Account

A test user account should be configured and used when troubleshooting user-reported failures or functionality issues. The test account should have the same level of privileges as the end user; otherwise, testing may yield different results.

Validating the Failure

The actual process for re-creating the failure should be known before the administrator tries to validate the failure. Usually, it's good to start with the end user who reported the problem. If the error, failure, or issue was reported by monitoring software, the server should be checked to see whether the system appears to be functional and the services or applications are running. If the system, services, and/or applications are still running, connectivity then needs to be tested. If the application is network based, as most are, network connectivity to the server should be tested first, followed by testing the application itself using the appropriate client software.

Locating Application and Service Dependencies

To isolate failures associated with applications and services, the administrator needs to understand and be aware of any service dependencies. For example, if a report indicates that Internet email has not been received, the problem could be the mail server, or it could be a dependency such as the firewall or DNS server for the email domain. If the Internet DNS server for the email domain is down or offline, the failure is not the mail server but merely the Internet DNS server, because other organizations are dependent on first locating the host record for mail from that DNS server before mail can be delivered.

To determine the network dependencies of a particular network application, refer to the manufacturer's documentation. If it is a Windows Server 2003 application, refer to Windows Server 2003 Help and Support for detailed information. If a server application runs as a Windows Server 2003 service, using the Services applet from the Administrative Tools menu, you can learn a service's dependencies on other services or system drivers, as shown in Figure 33.1 for the Windows Server 2003 DNS Server service.

Figure 33.1. DNS Server service dependencies.

Previous Page
Next Page


Site Failure Recovery

When a site becomes unavailable because of a physical access limitation or a disaster such as a fire or earthquake, steps must be taken to provide any mission-critical applications or business services from a separate location.

Creating Redundant and Failover Sites

Redundant sites are created for a few reasons: First, they can be created for load balancing or providing higher performance to clients accessing the resources from different geographic locations. For example, an organization may have one site in San Francisco, California, and another in Tampa, Florida, both on different coasts of the United States. East coast clients would connect to Florida, and West coast clients would connect to California. Each site would be a mirror of the other, so the data and services provided at each location would be the same.

Another reason for redundant sites is to provide if not all the computer-based services and applications available at the main site, at least all the mission-critical resources. This way, a company can continue to function, perhaps in a limited capacity, but at least it would be able to perform most important business functions.

For more information on deciding what services and applications are most important to a business and whether they should be provided in a failover site, refer to the section "Prioritizing the Environment" in Chapter 32.

Because every organization has different requirements when it comes to designing a failover site and what it takes to fail over and eventually fail back, this section covers the basic necessities for failing over between redundant sites to be successful.

Planning for Site Failover

Companyabc.com is a fictitious marketing/graphic design firm headquartered in New York, New York. The company has a secondary failover location in Boston, Massachusetts. The New York site provides virtual private network (VPN) and Terminal Services for the Marketing department employees who rarely make it into the office. Because marketing is the core of Companyabc.com's business, the VPN and Terminal Services are key to business continuity. For example, as the graphic artists develop new material for the Marketing department, the Marketing department sales force and client teams use the VPN to get the data to the client for approval. Also, the New York location houses the accounting server, which is used by employees to enter daily time sheets, which in turn are used to generate invoices to bill the clients. If the New York site becomes unavailable, VPN, Terminal Services, file servers containing client documentation, and the accounting servers must all be restored at the Boston site within a few hours of a site disaster for business continuity. In this scenario, restoring is a relatively simple task; most organizations are much more complicated than this.

Creating the Failover Site

When an organization decides to plan for site failures as part of a disaster recovery solution, there are many areas that need to be addressed and there can be many options to choose from. Using the Companyabc.com scenario, the biggest factors are file data and remote network connectivity through VPN and Terminal Services. This means that network connectivity is a priority, along with spare servers that can accommodate the user load. The spare servers for file data and accounting need to have enough disk space to accommodate a complete restore. As a best practice to ensure a smooth transition, the following list of recommendations provides a starting point:

  • Allocate the appropriate hardware devices including servers with enough processing power and disk space to accommodate the restored machines' resources.

  • Host the organization's DNS zones and records using primary DNS servers located either at an Internet service provider (ISP) co-location facility or have redundant DNS servers registered for the domain and located at both the physical locations.

  • Ensure that DNS record-changing procedures are documented and available at the remote site or at an offsite data storage location.

  • For the VPN and Terminal servers, ensure that the host records in the DNS tables are set to low Time to Live (TTL) values so that DNS changes do not take extended periods to propagate across the Internet. Microsoft Windows Server 2003 default TTL time is one hour.

  • Ensure that network connectivity is already established and stable between sites and between each site and the Internet.

  • Replicate file data between the two sites as often as possible.

  • Create at least two copies of backup media (tapes) that contain backed-up or archived company data. One copy should remain at the headquarters. A second copy should be stored with an offsite data storage company. An optional third copy could be stored at another site location; that copy can be used to restore the file to spare hardware on a regular basis to restore Windows if a site failover is necessary.

  • Have a copy of all disaster recovery documentation stored at multiple locations as well as at the offsite data storage company. This will provide redundancy should a recovery become necessary.

Allocating hardware and making the site ready to act as a failover site are simple tasks in concept, but the actual failover and fail-back process can be troublesome. Keep in mind that the preceding list applies to failover sites, and not mirrored or redundant sites configured to provide load balancing.

Failing Over Between Sites

Before failing over between sites can be successful, administrators need to be aware of what services need to fail over and in which order of precedence. For example, before an Exchange Server 2003 server can be restored, Active Directory domain controllers, global catalog servers, and DNS servers must be available.

As a site failure example, at Companyabc.com's headquarters in New York, a fire in the building leaves the server room soaked in fire retardant chemicals and the servers damaged. Failing services over to the Boston location would be necessary in this case.

To keep such a cutover at a high level, the following tasks need to be executed in a timely manner:

  • Update Internet DNS records pointing to the VPN and Terminal servers.

  • Restore any necessary Windows Server 2003 domain controllers, global catalog servers, and internal DNS servers as necessary.

  • Restore VPN and Terminal servers.

  • Restore the file and accounting servers and restore the latest available backup tape when restoring data.

  • Test client connectivity, troubleshoot, and provide remote and local client support as needed.

Failing Back After Site Recovery

When the initial site is back online and available to handle client requests and provide access to data and networking services and applications, it is time to consider failing back the services. This can be a controversial subject because fail-back procedures are normally more difficult than the initial failover procedure, but usually only when database servers are involved. Most organizations plan on the failover and have a tested failover plan that may include database log shipping to the disaster recovery site. However, they do not plan how they can get the current data back to the restored servers in the main or preferred site.

Questions to consider for failing back are as follows:

  • Will downtime be necessary to resynchronize data or databases between the sites?

  • When is the appropriate time to fail back?

  • Is the failover site less functional than the preferred site? In other words, are only mission-critical services provided in the failover site or is it a complete copy of the preferred site?

The answers really lie in the complexity of the failed-over environment. If the cutover is simple, there is no reason to wait to fail back.

Providing Alternative Methods of Client Connectivity

When failover sites are too expensive and not an option, that does not mean that an organization cannot plan for site failures. Other lower-cost options are available but depend on how and where the employees do their work. For example, remote salespeople in Companyabc.com most likely have laptops with all the necessary applications they need installed locally. On the other hand, the accounting employees probably do not have laptops, and even if they did, they would need to access the accounting server to query the updated time entries and generate customer invoices.

The following are some ways to deal with these issues without renting or buying a separate failover site:

  • Consider renting racks or cages at a local ISP to co-locate servers that can be accessed during a site failure.

  • Have users dial in from home to a Terminal server hosted at an ISP to access applications and file data, including the accounting server data.

  • Configure important folders for remote users with laptops so that they can have offline copies stored on their laptops that will synchronize with the server when the connection becomes available.

  • Rent temporary office space, printers, networking equipment, and user workstations with common standard software packages such as Microsoft Office and Internet Explorer. You can plan for and execute this option in about one day. If this is an option, be sure to find a computer rental agency first and get pricing before a failure occurs and you have no choice but to pay the rental rates.


Recovering from a Disk Failure

While organizations create disaster recovery plans and procedures to protect against a variety of system failures, disk failures tend to be the most common in networking environments. The technology used to create processor chips and memory chips has improved drastically over the past couple of decades, minimizing the failure of system-boards. And although the quality of hard drives has also drastically improved over the years, because hard drives are constantly spinning, they have the most moving parts in a computer system and tend to be the items that fail most often.

Hardware-Based RAID Array Failure

Common uses of hardware-based disk arrays for Windows servers include RAID 1 (mirroring) for the operating system and RAID 5 (striped sets with parity) for separate data volumes. Some deployments use a single RAID 5 array for the OS, and data volumes for RAID 0/1 (mirrored striped sets) have been used in more recent deployments.

RAID controllers provide a firmware-based array management interface, which can be accessed during system startup. This interface enables administrators to configure RAID controller options and manage disk arrays. This interface should be used to repair or reconfigure disk arrays if a problem or disk failure should occur.

Many controllers offer Windows-based applications that can be used to manage and create arrays. Of course, this requires that the operating system can be started to access the Windows-based RAID controller application. Follow manufacturer's procedures on replacing a failed disk within hardware-based RAID arrays.

Note

Many RAID controllers allow an array to be configured with a hot spare disk. This disk automatically joins the array when a single disk failure occurs. If several arrays are created on a single RAID controller card, hot spare disks can be defined as global and can be used to replace a failed disk on any array. As a best practice, hot spare disks should be defined for arrays.

Re-creating the System Volume

If a system disk failure is encountered, the system can be left in a completely failed state. To prevent this problem from occurring, the administrator should always try to create the system disk on a fault-tolerant disk array such as RAID 1 or RAID 5. If the system disk was mirrored (RAID 1) in a hardware-based array, the operating system will operate and boot normally because the disk and partition referenced in the boot.ini file will remain the same and will be accessible. If the RAID 1 array was created within the operating system using Disk Manager or diskpart.exe, the mirrored disk can be accessed upon bootup by choosing the second option in the boot.ini file during startup. If a disk failure occurs on a software-based RAID 1 array during regular operation, no system disruption should be encountered.

Installing the Boot Volume

If Windows Server 2003 has been installed on the second or third partition of a disk drive, a separate boot and system partition will be created. Most manufacturers require that for a system to boot up from a volume other than the primary partition, the partition must be marked active prior to functioning. To satisfy this requirement without having to change the active partition, Windows Server 2003 always tries to load the boot files on the first or active partition during installation regardless of which partition or disk the system files will be loaded on. When this drive or volume fails, if the system volume is still intact, a boot disk can be used to boot into the OS and make the necessary modification after changing the drive. Refer to "Creating a Windows Server 2003 Boot Floppy" in Chapter 32 for details on how to create a boot disk.

Regaining Data Volume Access

A data volume is by far the simplest of all types of disks to recover. If an entire disk fails, simply replacing the disk, assigning the previously configured drive letter, and restoring the entire drive from backup will restore the data and permissions.

A few issues to watch out for include the following:

  • Setting the correct permissions on the root of the drive

  • Ensuring that file shares still work as desired

  • Validating that data in the drive does not require a special restore procedure


Resolving Boot Failure Problems

Occasionally, a Windows Server 2003 system can suffer a service or application startup problem that could leave a server unable to complete a normal bootup sequence. Because the operating system cannot be accessed in this case, the system would remain unavailable until this problem can be resolved.

Windows Server 2003 includes a few alternative bootup options to help administrators restore a server to a working state. Several advanced bootup options can be accessed by pressing the F8 key when the boot loader screen is displayed. If the Recovery Console was previously installed, it is listed as an option in the boot loader screen. The Advanced boot options include:

  • Safe Mode This mode starts the operating system with only the most basic services and hardware drivers and disables networking. This allows administrators to access the operating system in a less functional state to make configuration changes to service startup options, some application configurations, and the System Registry.

  • Safe Mode with Networking This option is the same as Safe Mode, but networking drivers are enabled during operation. This mode also starts many more operating system services upon startup.

  • Safe Mode with Command Prompt This option is similar to the Safe Mode option; however, the Windows Explorer shell is not started by default.

  • Enable Boot Logging This option boots the system normally, but all the services and drivers loaded at startup are recorded in a file named ntbtlog.txt located in the %systemroot% directory. The default location for this file is c:\Windows\ntbtlog.txt. To simplify reading this file, the administrator needs to delete the existing file before a bootup sequence is logged so that only the information from the last bootup is logged.

  • Enable VGA Mode This mode loads the current display driver, but it displays the desktop at the lowest resolution. This mode is handy if a server is plugged in to a different monitor that cannot support the current resolution.

  • Last Known Good Configuration This mode starts the operating system using Registry and driver information saved during the last successful logon.

  • Directory Services Restore Mode This mode is only for domain controllers and allows for maintenance and restore of the Active Directory database or the SYSVOL folder.

  • Debugging Mode This mode sends operating system debugging information to other servers through a serial connection. This requires a server on the receiving end with a logging server that is prepared to accept this data. Most likely, standard administrators will never use this mode.

  • Start Windows Normally As the name states, this mode loads the operating system as it would normally run.

  • Reboot This option reboots the server.

  • Return to OS Choices Menu This option returns the screen back to the boot loader page so the correct operating system can be chosen and started.

The Recovery Console

The Recovery Console provides an option for administrators to boot up a system using alternate configuration files to perform troubleshooting tasks. Using the Recovery Console, the bootup sequence can be changed, alternate boot options can be specified, volumes can be created or extended, and service startup options can be changed. The Recovery Console has only a limited number of commands that can be used, making it a simple console to learn. If Normal or Safe mode bootup options are not working, the administrator can use the Recovery Console to make system changes or read the information stored in the boot logging file using the type command. The boot logging file is located at C:\Windows\ntbtlog.txt by default and exists only if someone tried to start the operating system using any of the Safe mode options or the boot logging option.


Recovering from a Complete Server Failure

Because hardware does occasionally fail, and in the real world operating systems do have problems, a server recovery plan is essential, even though it may never be used. The last thing any administrator wants is a server failure to occur and to end up on the phone with Microsoft Technical support telling him to restore the server from backup when he does not have a plan ready. To keep from being caught unprepared, the administrator should have a recovery plan for every possible failure associated with Windows Server 2003 systems.

Restoring Versus Rebuilding

When a complete system failure occurs, whether it is because of a site outage, a hardware component failure, or a software corruption problem, the method of recovery depends on the major goal the administrator is trying to accomplish. The goal is to get the server up and running, of course, but behind the scenes many more questions should be answered before the restore is started:

  • How long will it take to restore the server from a full backup?

  • If the server failed because of software corruption, will restoring the server from backup also restore the corruption that actually caused the failure?

  • Will reloading the operating system and applications manually followed by restoring the system state be faster than a full restore?

Loading the Windows Server 2003 operating system and applications can be a relatively efficient operation. This ensures that all the correct files and drivers are loaded correctly, and all that needs to follow is a system state restore to recover the server configuration and restore the data. One of the problems that can occur is that, upon installation, some applications generate Registry keys based on the system's computer name, which can change if a system state restore is performed. Other applicationsfor example, Exchange Server 2003can be restored using a /disasterrecovery installation switch and do not need the server's system state restore, just the original computer name and domain membership, as long as computer and user certificates are not being used.

The key to choosing whether to rebuild or restore from backup is understanding the dependencies of the applications and services to the operating system and having confidence in the server's stability at the time of the previous backups. The worst situation is attempting a restore from backup that takes several hours, only to find that the problem has been restored as well.

Manually Recovering a Server

When a complete server system failure is encountered and the state of the operating system or an application is in question, the operating system can be recovered manually. Locating the system's original configuration settings is the first step. This information is normally stored in a server configuration document or wherever server configuration information is kept.

Because each system is different, as a general guideline for restoring a system manually, perform the following steps:

1. | Install a new operating system on the original system hardware and disk volume, or as close to the original configuration as possible. Be sure to install the same operating system versionfor example, Windows Server 2003 Enterprise or Standard Server.
2. | During installation, name the system using the name of the original server but do not join a domain.
3. | Do not install any additional services during installation and proceed by performing a basic installation.
4. | After the operating system completes installation, install any additional hardware drivers as necessary and update the operating system to the latest service pack and security patches. To reduce compatibility problems, install the service packs and updates as outlined in the server configuration document to ensure that any installed applications will function as desired. During a restore is not the time to roll out additional system changes. The goal is to get the system back online, not to upgrade it.
5. | Using the Disk Management console, create and format disk volumes and assign the correct drive letters as recorded in the server build document.
6. | If the server was originally part of a domain, you must first reset the computer account using the AD users and computers console and join the domain afterwards. This will ensure that permissions and group membership previously granted to this computer remain intact.
7. | Install any additional Windows Server 2003 services as defined in the server build document.
8. | Install any Microsoft server applications following any special recovery processes and restore application data immediately following the application restore.
9. | Install any third-party applications and restore configurations and data as necessary.
10. | Test functionality, add this system to the backup schedule, and start a full backup.

Note

If certificates were issued to the previous server for secure data communication, the new server must enroll with the Certification Authority (CA) for a new certificate before encrypted communication can occur.

Restoring a Server Using a System State Restore

When an operating system fails and cannot be started, a restore of the entire server may be necessary. If system volumes and data volumes exist on the same disk, performing an Automated System Recovery (ASR) restore will wipe out the entire disk, and both the system and data will need to be restored. In many cases, an ASR restore is not necessary; recovering only the system volume and system state is necessary.

After this process is complete, restores of the applications and application data should proceed. To recover a system using a clean installation and a previously backed-up system state, follow these steps:

1. | Shut down the original server.
2. | Install a new operating system on the original system hardware and disk volume, or as close to the original configuration as possible. Be sure to install the same operating system versionfor example, Windows Server 2003 Enterprise or Standard Server.
3. | During installation, name the system using the name of the original server but do not join a domain. Note If the machine is joined to the original domain during the clean installation, a new security identifier (SID) will be generated for the machine account. A system state restore after this would restore an invalid computer SID, and many services and applications will fail.
4. | Do not install any additional services during installation and proceed by performing a basic installation.
5. | After the operating system completes installation, install any additional hardware drivers as necessary and update the operating system to the latest service pack and security patches. To reduce compatibility problems, install the service packs and updates as outlined in the server build document to ensure that any installed applications will function as desired.
6. | Using the Disk Management console, create and format disk volumes and assign the correct drive letters as recorded in the server build document.
7. | After the installation, restore any necessary drivers or updates to match the original configuration. This information should be gathered from a server configuration document (server build document). Then reboot as necessary.

After all the updates are installed, restore the previously backed-up system state data; afterward, restore any additional application or user data.

System State Restore

This section outlines how to restore the system state to a member or stand-alone Windows Server 2003 system. To restore the system state, perform the following steps:

1. | Click Start, All Programs, Accessories, System Tools, Backup.
2. | If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.
3. | Click the Restore Wizard (Advanced) button to start the Restore Wizard.
4. | Click Next on the Restore Wizard Welcome screen to continue.
5. | On the What to Restore page, select the appropriate cataloged backup media, expand the catalog selection, and check System State. Click Next to continue.
6. | If the correct tape or file backup media does not appear in this window, cancel the restore process. Then, from the Restore Wizard, locate and catalog the appropriate media and return to the restore process from step 1.
7. | On the Completing the Restore Wizard page, click Finish to start the restore.
8. | When the restore is complete, review the backup log for detailed information and click Close on the Restore Progress window when finished.
9. | Reboot the system as prompted.
10. | When the system restarts, log in using an account with Local and/or Domain Administrator rights as necessary.
11. | After the system state is restored, install any additional applications and data if necessary.

Restoring a System Using ASR Restore

When a system has failed and all other recovery options have been exhausted, an ASR restore can be performed, provided that an ASR backup has been previously performed. The ASR restore will restore all disk and volume configurations, including redefining volumes and formatting them. This means that the data stored on all volumes needs to be restored after the ASR restore is complete. This restore brings a failed system back to complete server operation, except for certain applications that may require special configurations after the restore. For example, the Remote Storage service data needs to be restored separately.

Note

An ASR restore re-creates all disk volumes, but if a new or alternate system is being used, each disk must be of equal or greater size to the disks on the original server. Otherwise, the ASR restore will fail.

To perform an ASR restore, follow these steps:

1. | Locate the ASR floppy created for the failed node or create the floppy from the files saved in the ASR backup media. For information on creating the ASR floppy from the ASR backup media, refer to Help and Support from any Windows Server 2003 Help and Support tool.
2. | Insert the Windows Server 2003 operating system media in the CD-ROM drive of the server you are restoring to and start the installation from this CD.
3. | When prompted, press F6 to install any third-party storage device drivers if necessary. This includes any third-party disks or tape controllers that Windows Server 2003 will not natively recognize.
4. | Press F2 when prompted to perform an Automated System Recovery.
5. | Insert the ASR floppy disk into the floppy drive and press Enter when prompted. If the system does not have a local floppy drive, one must temporarily be added; otherwise, an ASR restore cannot be performed.
6. | The operating system installation proceeds by restoring disk volume information and reformatting the volumes associated with the operating system. When this process is complete, the operating system will restart after a short countdown, the graphic-based OS installation will begin, and the ASR backup will attempt to reconnect to the backup media automatically. If the backup media is on a network drive, the ASR backup reconnection will fail. If it fails, specify the network location of the backup media using a UNC path and enter authentication information if prompted.
7. | When the media is located, open the media and click Next and then Finish to begin recovering the remaining ASR data.
8. | When the ASR restore is complete, if any local disk data was not restored with the ASR restore, restore all local disks.
9. | Click Start, All Programs, Accessories, System Tools, Backup.
10. | If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.
11. | Click the Restore Wizard (Advanced) button to start the Restore Wizard.
12. | Click Next on the Restore Wizard Welcome screen to continue.
13. | On the What to Restore page, select the appropriate cataloged backup media, expand the catalog selection, and check desired data on each local drive. Click Next to continue.
14. | On the Completing the Restore Wizard page, click Finish to start the restore. Because you want to restore only what ASR did not, you do not need to make any advanced restore configuration changes.
15. | When the restore is complete, reboot the server if prompted.
16. | After the reboot is complete, log on to the restored server and check server configuration and functionality.
17. | If everything is working properly, perform a full backup and log off the server.

Restoring the Boot Loader File

When a Windows Server 2003 system is recovered using an ASR restore, the boot.ini file may not be restored. This file contains the options for booting into different operating systems on multiboot systems and booting into the Recovery Console if it was previously installed. To restore this file, simply restore it from backup to an alternate folder or drive. Delete the boot.ini file from the C:\ root folder and move the restored file from the alternate location to C:\ or whichever drive the boot.ini file previously was located on.


Resolving Windows Server 2003 Networking Services Errors

Backing up Windows Server 2003 systems requires only a small amount of knowledge to perform the few backup tasks. More information is necessary when it comes to recovery, however, because of two distinct reasons: Several Windows Server 2003 services can be restored to a previous configuration without affecting the entire system, and others have special restore requirements.

Repairing Certificate Services

When a server running Certificate Services needs to be recovered, the Certificate server and database can normally be recovered using a system state restore. If the server was recovered using a clean installation with the same server name, the system must not join the domain at first. The system state must be restored to recover the computer account SID for the certificate server. If the CA server system state has not been backed up or cannot be restored properly, the CA may not be recoverable. When the CA service is recovered using a system state restore, the certificate database can be recovered if the correct version was not restored already.

To restore the Certification Authority if the database is corrupted or if an issued certificate is deleted by mistake, the administrator should restore the CA database. If the Certification Authority does not start or cannot issue certificates properly, the CA private key and CA certificate should be restored.

Only if the Certification Authority was previously backed up as outlined in Chapter 32 can the CA database be restored independently of a system state restore. The following sections assume that a previous backup was performed and saved to the c:\CaBackup directory of the CA server.

Restoring the CA Private Key and CA Certificate

To restore the CA private key and CA certificate, perform the following steps:

1. | Log on to the Certification Authority server using an account with Local Administrator rights.
2. | Click Start, All Programs, Administrative Tools, Certification Authority.
3. | Expand the Certification Authority server and select the correct CA.
4. | Select Actions, All Tasks, Restore CA.
5. | A pop-up message appears stating that Certificate Services will need to be stopped during this operation. Click OK to stop the service.
6. | Click Next on the Certification Authority Restore Wizard Welcome screen.
7. | On the Items to Restore page, check the Private Key and CA Certificate boxes, type in the path of the backup folder, and click Next.
8. | Enter the password previously specified during the CA private key and certificate backup process.
9. | On the Completing the Certification Authority Restore Wizard page, click Finish to restore the private key and certificate and restart the Certification Authority service.
10. | In the Certification Authority window, right-click Certification Authority and select Properties.
11. | On the General tab of the CA's property page, verify that the correct certificate was restored. Then click OK to close the CA property pages, close the Certification Authority console, and log off the server.
Restoring the CA Database

The CA database will be restored more often than the CA private key and certificate will be restored, although it may not be necessary very often. The CA database may need to be restored if a user's or machine's certificate was revoked mistakenly and needs to be recovered. Also, if the certificate database is corrupted, the database could be recovered to a previous state. When a database is recovered, any new certificates that were issued after the backup was performed will become invalid. Users and computers issued these certificates may need to request new certificates and may not be able to recover encrypted data. To avoid this problem, the administrator needs to back up the certificate database frequently using a system state backup. As a best practice, CA servers should be deployed on member servers to simplify the restore process.

To restore the CA database from a previous backup, perform the following steps:

1.
Log on to the Certification Authority server using an account with Local Administrator rights.

2.
Click Start, All Programs, Administrative Tools, Certification Authority.

3.
Expand the Certification Authority server and select the correct CA.

4.
Select Actions, All Tasks, Restore CA.

5.
A pop-up message appears stating that Certificate Services will need to be stopped during this operation. Click OK to stop the service.

6.
Click Next on the Certification Authority Restore Wizard Welcome screen.

7.
On the Items to Restore page, check the Certificate Database and Certificate Database Log box and type in the path of the backup folder, as shown in Figure 33.2. Then click Next.

Figure 33.2. Restoring the certificate database from a backup folder.

8.
On the Completing the Certification Authority Restore Wizard page, click Finish to restore the certificate database and certificate database log and restart the Certification Authority service.

9.
After the restore is complete, a pop-up window appears asking you to start Certificate Services. If additional incremental restores are necessary, click No and continue the restore process; otherwise, click Yes.

10.
In the Certification Authority window, select the revoked certificates, issued certificates, or other locations to ensure that the correct database has been restored. Then click OK to close the CA property pages, close the Certification Authority console, and log off the server.

Re-establishing Dynamic Host Configuration Protocol

If a previous backup of the Dynamic Host Configuration Protocol (DHCP) database was performed manually using the DHCP console or if the default 60-minute database backup is being used, the following steps will restore a DHCP database to the original DHCP or an alternate DHCP server. The DHCP restore will restore server options, scopes, and scope options, including reservations, address leases, and address pools. The DHCP data will be restored in its entirety. If only a single lost configuration needs to be restoredfor example, a reservationthe DHCP data can be restored to an alternate server with the DHCP service installed. This server does not need to be authorized in the forest. When the DHCP data is restored, the reservation information can be recorded and manually recreated on the original DHCP server.

To restore DHCP data to the original or an alternate DHCP server, follow these steps:

1.
If a system was restored using a clean installation or ASR and the system state was restored, the DHCP data will have be restored. If a configuration change in the DHCP needs to be rolled back, proceed to the next step.

2.
Locate the previously backed-up DHCP data, which by default is located in the c:\Windows\system32\dhcp\backup folder. If this folder does not exist on the local system, restore the folder from a previous backup to an alternate locationfor example, c:\dhcprestore\.

3.
Log on to the desired DHCP server using an account with Local and Domain Administrator permissions.

4.
Click Start, All Programs, Administrative Tools, DHCP.

5.
If the desired DHCP server is not listed, right-click DHCP in the left pane and choose Add Server.

6.
Type in the fully qualified domain name of the desired DHCP server and click OK.

7.
When the server is listed in the window, select and right-click the server. Then select Restore, as shown in Figure 33.3.

Figure 33.3. Restoring the DHCP data.

[View full size image]

8.
In the Browse for Folder window that is displayed, locate the previously backed-up DHCP data, select the folder, and click OK. This DHCP backup folder will be accessed on the local system drive in the %systemroot%\system32\dhcp\backup folder or in an alternate restore folder.

9.
A pop-up message appears stating that the DHCP service will need to be stopped and restarted for changes to take effect. Click Yes to restore the data and restart the DHCP server.

10.
When the restore is complete, you might need to refresh the DHCP console. Select Action, Refresh, if necessary, to view changes.

11.
To verify operation, boot up a DHCP client and check for proper addressing information and scope options. Also, check to ensure that reservations, if used, have been restored to the DHCP server configuration.

12.
Close the DHCP console and log off the server.

Note

The DHCPExim utility can be used to quickly export and import DHCP configuration information to a file for safekeeping. This tool can be downloaded from Microsoft's Web site at http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/dhcpexim-o.asp.

Windows Internet Naming Service

When the Windows Internet Naming Service (WINS) needs to be recovered from a previous backup, it can be recovered only from a system state backup or using the last-saved WINS backup store in the %systemroot%\system32\WINS\Backup folder. The default for WINS server backup is during system shutdown. If more frequent backups are necessary, perform the backup as outlined in the "Creating Regular Backup Procedures" section in Chapter 32.

To restore the WINS data, follow these steps:

1.
Log on to the WINS server using an account with Local Administrator access.

2.
Click Start, All Programs, Administrative Tools, WINS.

3.
If the local WINS server does not appear in the window, right-click WINS in the left pane and select Add Server.

4.
Type in the NetBIOS or fully qualified domain name of the WINS server and click OK.

5.
Select the WINS server in the left pane.

6.
Right-click the WINS server, select All Tasks, and then select Stop to stop the WINS service, as shown in Figure 33.4.

Figure 33.4. Stopping the WINS service.

[View full size image]

7.
After the service is stopped, right-click the server icon and select Restore Database.

8.
In the Browse for Folder window that is displayed, locate the previously backed-up WINS data, select the folder, and click OK.

9.
After the restore is complete, the WINS service is automatically restarted. Verify that the correct WINS configurations and records have been restored.

10.
Troubleshoot as necessary, close the WINS console, and log off the server.

Recovering Domain Name System

Domain name system (DNS) zones can be created or restored using zone files created on Windows Server 2003 or from other DNS systems. Because dynamic Active Directoryintegrated zones do not store a copy of the data in a backup file, these zones can be simply re-created and the servers and workstations will repopulate the data within. Entries manually entered in the Active Directoryintegrated zones will need to be manually re-created. This is why multiple Active Directory DNS servers are desired to provide redundancy.

To restore standard primary zones from a backup file, simply create a new forward or reverse lookup zone but specify to create it using the existing backup file. Creating new zones on Windows 2003 DNS is covered in Chapter 9, "The Domain Name System."


Re-creating Windows Server 2003 File Services and Data

To recover file and folder data reported to be corrupt, accidentally deleted, or just missing from a server share or volume, the administrator must first verify the report. If a single file is reported corrupt, the administrator should verify file share and NTFS permissions to the file and parent folder to ensure that the error is not access related. After the error is confirmed, the administrator should request that the user show him the problem. If the file is corrupted, it should be restored from backup using one of the methods outlined in the following sections.

If data is reported lost or deleted on a volume, the administrator should first search for the file within subfolders on the same volume. If a user has the permissions to modify files on more than one folder on a volume, there is a chance that the missing file or folder was mistakenly dragged and dropped to a different folder. After a search is completed, the data can be restored to the original location if it is found; otherwise, the data can be restored from backup using one of the methods outlined in the following sections.

Recovering Data Using NTBackup.exe

When data folders and/or files are corrupt, missing, or a previously backed-up copy is needed, the data can be restored using NTBackup.exe if a previous backup was performed using this utility. For example, if the Marketing folder was deleted from the D: drive of SERVER1, the following backup procedure could be used to restore the data:

1.
Log on to SERVER1 using an account that has at least the privileges to restore files and folders. Backup Operators and Local Administrator groups have this right by default.

2.
Click Start, All Programs, Accessories, System Tools, Backup.

3.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.

4.
Click the Restore Wizard (Advanced) button to start the Restore Wizard.

5.
Click Next on the Restore Wizard Welcome screen to continue.

6.
On the What to Restore page, select the appropriate cataloged backup media, expand the catalog selection, and select the Marketing folder from the D: drive backup, as shown in Figure 33.5.

Figure 33.5. Selecting the desired folder for restore.

7.
If the correct tape or file backup media does not appear in this window, cancel the restore process. Then, from the Restore Wizard, locate and catalog the appropriate media and return to the restore process from step 4.

8.
On the Completing the Restore Wizard page, click Finish to start the restore.

9.
When the restore is complete, review the backup log for detailed information and click Close on the Restore Progress window when finished.

Recovering Data with Volume Shadow Copy

The Volume Shadow Copy service can be used to restore missing files or restore previous versions of files only if shadow copies have been enabled on the volume. To enable shadow copies on a volume, refer to the installation steps outlined in the "Configuring Shadow Copies" section in Chapter 30, "File System Fault Tolerance." To restore data using shadow copies, the volume containing the data in question needs to be accessed from a share point. For example, if Volume Shadow Copy is enabled on the D: drive of SERVER1, to restore data using a shadow copy, the administrator can open a connection to \\SERVER1\D$.

Restoring shadow copy data allows the administrator to restore the data to the original location, or it can be copied and restored elsewhere. As an example, the Marketing folder on the SERVER1 D: drive will be restored after it is deleted. When a user reports that the Marketing folder is missing from SERVER1, follow these steps:

1.
Log on to SERVER1 with Administrator access to verify that the Marketing folder has been deleted.

2.
Open an Explorer window to the \\SERVER1\D$ location.

3.
After a few seconds, the View Previous Versions task is displayed, as shown in Figure 33.6. If the File and Folder Tasks section does not open, change the folder view.

Figure 33.6. Accessing data stored using shadow copies.

[View full size image]

4.
To change the folder options, select Tools, Folder Options. Under Tasks on the General tab, select Show Common Tasks in Folders and click OK to update the folder view.

5.
Select the View Previous Versions task in the left pane of the window.

6.
When the Share Properties page opens, select the Previous Versions tab if it is not already selected.

7.
In the Folder Version window, select the correct shadow copy and click the View button at the bottom of the window.

8.
For this example, select the Marketing folder and choose Copy.

9.
Close the Shadow Copy window and close the Share Properties page.

10.
Back in the \\SERVER1\D$ window, right-click a blank spot in the window and choose Paste to restore the marketing folder.

11.
Double-check permissions on the restored folder, close the window, and log off the server when you're finished.

Using Distributed File System Replication for File System Recovery

Another popular method of protecting the file system from data loss is to leverage the Distributed File System (DFS) replication technology to mirror information to another server. DFS is a solution that needs to be set up and running before a failure because the data needs to be replicated before a failover or recovery can take place. So this will require preplanning and implementation before the solution can be used.

To use DFS, a file system volume that is wanted for replication is identified, and a replica is created on another server. If the primary server fails, DFS automatically redirects users to access the mirrored copy of the data on the replica server.

For more details on the implementation of DFS for file system replication, see the section, "Using the Distributed File System Replication," in Chapter 30, "File System Fault Tolerance."


Restoring Internet Information Services

When Internet Information Services (IIS) data is erased or the service is not functioning as desired, restoring the configuration may be necessary. To restore the IIS metabase data, perform the following steps:

1. | Log on to the desired IIS server using an account with Local Administrator privileges.
2. | Click Start, Programs, Administrative Tools, Internet Information Services (IIS) Manager to open the IIS Manager console.
3. | Select the Web server in the left pane.
4. | Select Action, All Tasks, Backup/Restore Configuration.
5. | On the Configuration Backup/Restore page, there will be a listing of automatic backups that IIS has already performed. Select the desired backup and click the Restore button to perform a manual restore.
6. | A pop-up window opens stating that all Internet services will be stopped to restore the data and restarted afterward. Click Yes to begin the restore.
7. | When the restore is complete, a confirmation pop-up window is displayed. Click OK to close this window.
8. | Click Close on the Configuration Backup/Restore page.
9. | Back in the IIS Manager window, verify that the restore was successful, close the window, and log off the server when you're finished.

Backups are stored in the %systemroot%\system32\Inetsrv\MetaBack folder by default.

Recovering IIS Data and Logs

IIS Web and FTP folders are stored in the c:\InetPub\ directory. The default location for the IIS logs is the c:\Windows\system32\LogFiles folder. To recover the IIS Web site, FTP site, or IIS logs, restore the files using either shadow copy data or a backup/restore tool such as Ntbackup.exe. For detailed information on this process, refer to "Recovering Data with Volume Shadow Copy" and "Recovering Data Using NTBackup.exe," respectively.


Re-establishing the Cluster Service

Cluster nodes require that special backup and restore procedures be followed to ensure a successful recovery if a cluster failure is encountered. For detailed information on backing up and restoring a cluster node, refer to the "Backing Up and Restoring Clusters" section in Chapter 31 or use the Windows Sever 2003 Help and Support Tool.


Resolving Windows Server 2003 Domain Controller Failure

When a Windows Server 2003 domain controller fails, the administrator either needs to recover this server or understand how to completely and properly remove this domain controller from the domain. The following are some questions to consider:

  • Did this domain controller host any of the domain or forest Flexible Single Master Operations (FSMO) roles?

  • Was this domain controller a global catalog (GC) server, and if so, was it the only GC in a single Active Directory site?

  • If the server failed because of Active Directory corruption, has the corruption been replicated to other domain controllers?

  • Is this server a replication hub or bridgehead server for Active Directory site replication?

Using the preceding list of questions, the administrator can decide how best to deal with the failure. For example, if the failed domain controller hosted the PDC emulator FSMO role, the server could be restored, or the FSMO role could be manually seized by a separate domain controller. If the domain controller was the bridgehead server for Active Directory site replication, recovering this server may make the most sense so that the desired primary replication topology remains intact. The administrator should recover a failed domain controller as any other server would be recovered, restore the OS from an ASR restore or build a clean server, install all the necessary services, restore the system state, and perform subsequent restores of local drive data as necessary.


Restoring Active Directory

When undesired changes are made in Active Directory or the Active Directory database is corrupted on a domain controller, recovering the Active Directory database may be necessary. Restoring Active Directory can seem like a difficult task, unless frequent backups are performed and the administrator understands all the restore options.

Restoring the Active Directory Database

The Active Directory database contains all the information stored in Active Directory. The global catalog information is also stored in this database. The actual filename is ntds.dit and is by default located in the c:\Windows\NTDS\ directory. When a domain controller is restored from server failure, the Active Directory database is restored with the system state. If no special steps are taken when the server comes back online, it will ask any other domain controllers for a copy of the latest version of the Active Directory database. This situation is called a nonauthoritative restore of Active Directory.

When a change in Active Directory needs to be rolled back or if the entire database needs to be rolled back up across the enterprise or domain, an authoritative restore of the Active Directory database is necessary.

Active Directory Nonauthoritative Restore

When a domain controller is rebuilt from a backup after a complete system failure, simply recovering this server using a restore of the local drives and system state is enough to get this machine back into the production network. When the machine is back online and establishes connectivity to other domain controllers, any Active Directory and SYSVOL updates will be replicated to the restored server.

Nonauthoritative restores are also necessary when a single domain controller's copy of the Active Directory database is corrupt and is keeping the server from booting up properly. To restore a reliable copy of the Active Directory database, the entire system state needs to be restored, and if additional services reside on the domain controller, restoring the previous configuration data for each of these services may be undesirable. In a situation like this, the best option is to try to recover the Active Directory database using database maintenance and recovery utilities such as Esentutl.exe and Ntdsutil.exe. These utilities can be used to check the database consistency, defragment, and repair and troubleshoot the Active Directory database. For information on Active Directory maintenance practices with these utilities, refer to the Windows Server 2003 Help and Support.

To restore the Active Directory database to a single domain controller to recover from database corruption, perform the following steps:

1. | Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.
2. | When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and then press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.
3. | When the server boots up, log on using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.
4. | Click Start, Run.
5. | Type NTBackup.exe and click OK.
6. | When the Backup or Restore window opens, click the Advanced Mode hyperlink.
7. | Select the Restore and Manage Media tab.
8. | Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.
9. | Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.
10. | A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.
11. | A confirm restore window opens in which you can choose advanced restore options. Click OK to initiate the restore of the system state.
12. | When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because only a nonauthoritative restore of the Active Directory database is necessary, click Yes to restart the server.
13. | After the server reboots, log in as a Domain Administrator.
14. | Check the server event log and Active Directory information to ensure that the database has been restored successfully and log off the server when completed.
Active Directory Authoritative Restore

When a change made to Active Directory is causing problems or when an object is modified or deleted and needs to be recovered to the entire enterprise, an Active Directory authoritative restore is necessary.

To perform an authoritative restore of the Active Directory database, perform the following steps:

1. | Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.
2. | When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.
3. | When the server boots up, log in using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.
4. | Click Start, Run.
5. | Type Ntbackup.exe and click OK.
6. | When the Backup or Restore window opens, click the Advanced Mode hyperlink.
7. | Select the Restore and Manage Media tab.
8. | Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.
9. | Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.
10. | A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.
11. | A confirm restore window opens in which you can choose advanced restore options. Click OK to initiate the restore of the system state.
12. | When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because an authoritative restore of the Active Directory database is necessary, click No.
13. | Close the backup window and click Start, Run.
14. | Type cmd.exe and click OK to open a command prompt.
15. | At the command prompt, type nTDsutil.exe and press Enter.
16. | Type Authoritative restore and press Enter.
17. | Type Restore Database and press Enter to restore the entire database. Depending on whether this domain controller is in the forest root domain, a tree root domain, or a child domain in the Active Directory partitions, such as the schema partition and/or the domain naming context partition, the information will be replicated to all the other appropriate replication partner domain controllers.
18. | An authoritative restore confirmation dialog box appears; click Yes to start the authoritative restore.
19. | The command-prompt window displays whether the authoritative restore was successful. Close the command prompt and reboot the server.
20. | Boot up the server in Normal mode, log in, and open the correct Active Directory tools to verify whether the restore was successful. Also, check on other domain controllers to ensure that the restore is being replicated to them.
21. | When you're done, perform a full backup of the domain controller or at least the system state; then log off the server when the backup is complete.
Partial Active Directory Authoritative Restore

Most Active Directory authoritative restores are performed to recover from a modification or deletion of an Active Directory object. For example, a user account has been deleted instead of disabled, or an organizational unit's security has been changed and the administrator is locked out. Recovering only a specific object, such as a user account or an organizational unit or a container, requires the distinguished name (DN) of that object. To find the distinguished name, the administrator can use the Ntdsutil utility; however, if an LDIF dump of Active Directory exists, this file would be most helpful. If no LDIF file exists and the DN of the object to be recovered is unknown, recovery of the single object or container is not possible.

To simplify the steps to partial recovery, we will use an example of recovering a single user account using the logon Khalil that was previously contained in the Users container in the Companyabc.com domain. To restore the user account, follow these steps:

1.
Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.

2.
When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.

3.
When the server boots up, log in using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.

4.
Click Start, Run.

5.
Type Ntbackup.exe and click OK.

6.
When the Backup or Restore window opens, click the Advanced Mode hyperlink.

7.
Select the Restore and Manage Media tab.

8.
Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.

9.
Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.

10.
A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.

11.
A confirm restore window opens in which you can choose advanced restore options. Click OK to initiate the restore of the system state.

12.
When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because only a nonauthoritative restore of the Active Directory database is necessary, click No.

13.
Close the backup window and click Start, Run.

14.
Type cmd.exe and click OK to open a command prompt.

15.
At the command prompt, type ntdsutil.exe and press Enter.

16.
Type Authoritative restore and press Enter.

17.
Type Restore Object "cn=Khalil,cn=Users,dc=companyabc,dc=com" and press Enter, as shown in Figure 33.7.

Figure 33.7. Restoring a single user account.

[View full size image]

18.
The success or failure of the restore appears in the command prompt. Now type quit and press Enter. Repeat this step until you reach the C: prompt.

19.
Close the command-prompt windows and reboot the server.

20.
Log on to the server with a Domain Administrator account and verify that the account has been restored. Then log off the server.

Rebuilding the Global Catalog

There are no special restore considerations for restoring a global catalog server other than those outlined for restoring Active Directory in the previous sections. The global catalog data is re-created based on the contents of the Active Directory database.

Restoring the SYSVOL Folder

The SYSVOL folder contains the system policies, Group Policies, computer startup/shutdown scripts, and user logon/logoff scripts. If a previous version of a script or Group Policy Object is needed, the SYSVOL folder must be restored. As a best practice and to keep the process simple, the SYSVOL folder should be restored to an alternate location where specific files can be restored. When the restored files are placed in the SYSVOL folder, the File Replication Service will recognize the file as new or a changed version, and it will replicate it out to the remaining domain controllers. If the entire SYSVOL folder needs to be pushed out to the remaining domain controllers and the Active Directory database is intact, a primary restore of the SYSVOL is necessary.

To perform a primary restore of the SYSVOL folder, follow these steps:

1.
Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.

2.
When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.

3.
When the server boots up, log in using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.

4.
Click Start, Run.

5.
Type Ntbackup.exe and click OK.

6.
When the backup or restore window opens, click the Advanced Mode hyperlink.

7.
Select the Restore and Manage Media tab.

8.
Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.

9.
Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.

10.
A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.

11.
A confirm restore window opens in which you can choose advanced restore options. Click the Advanced button to view the advanced restore options.

12.
Check the box labeled When Restoring Replicated Data Sets, Mark the Restored Data as the Primary Data for All Replicas, as shown in Figure 33.8.

Figure 33.8. Choosing to perform a primary restore.

13.
Click OK to return to the Confirm Restore page and click OK to start the restore.

14.
When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because only a nonauthoritative restore of the Active Directory database is necessary, click Yes to restart the server.

15.
After the server reboots, log in using an account with Domain Administrator access.

16.
Check the server event log and the SYSVOL folder to ensure that the data has been restored successfully and log off the server when you're finished.


Recovering the Removable Storage Database

If Remote Storage is installed on a system or Ntbackup.exe is used, the media used by both services are managed by the Removable Storage service. The Removable Storage service stores information concerning media stored in tape devices, including tape libraries. The information kept in the database may include a list of all the media pools and media contained within each pool. The service database also contains media labels and other media-related information.

In the event of a system failure in which the operating system needs to be loaded from scratch and removable storage media information needs to be restored, follow this procedure to restore the removable media database:

1.
If the operating system is not in a recoverable state, reinstall the OS if necessary.

2.
Locate the backup media containing the most recent or desired backup of the removable storage database. These files are located in the %systemroot%\system32\NTMSData folder. To locate the latest copy of the database, insert the most recent backup tape or tapes into the backup device and catalog them.

3.
After you insert the tape into the backup device, open Computer Management from the Administrative Tools menu.

4.
In the left pane, select the plus sign next to Storage to expand it and expand Removable Storage and Libraries.

5.
Under Libraries, right-click the appropriate backup device and choose Inventory.

6.
When the tape device completes the inventory process, the tape information will be listed in the right pane. Note the location information stating which media pool it is currently in.

7.
Place the media in the backup media pool. The backup media pool has submedia pools for the type of media device. For example, see the DLT media pool shown in Figure 33.9.

Figure 33.9. Selecting the DLT backup media pool.

[View full size image]

8.
In the left pane, click the plus sign to expand Media Pools and then expand Backup Media Pool. If the backup media pool does not exist, opening Ntbackup.exe automatically creates the media pool.

9.
If you used only the plus signs to expand the listings, the inventoried media will still be listed in the right pane. If not, select the appropriate tape device in the left pane as previously outlined.

10.
Click and drag the backup media on the right to the backup media pool in the left pane.

11.
Close Computer Management.

Note

The process described in steps 5 through 9 is necessary; otherwise, when Ntbackup.exe is opened, it will recognize the media as imported or foreign media and will prompt you to overwrite the media to allocate it to the free media pool. You do not want this result.

12.
Click Start, All Programs, Accessories, System Tools, Backup.

13.
If this is the first time you've run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.

14.
Click the Restore and Manage Media tab and select either a file or the correct tape device type to start a catalog. The catalog will run one level at a time, so to view the files in the NTMSData directory, you may need to browse a few times.

15.
When the tape is cataloged, review the actual files in the NTMSData directory for last modified date to decide whether these versions of the files are recent enough.

16.
Select all the files within the NTMSData directory, and in the Restore Files To section, select Alternate Location. For the path, specify a restore location. If necessary, use Windows Explorer to create a directory and specify that path in the backup program.

Note

The entire folder hierarchy of the files will be restored. To reduce the chance of confusion, use a specified subfolder for the restore point, such as c:\RestoredData\.

17.
Click the Start Restore button to start the restore process. In the Confirm Restore window, click OK to start the restore.

18.
When the backup is complete, close the Restore Progress window and close the backup program.

19.
Open My Computer or Windows Explorer and locate the files in the restored location. Select all the files, right-click them, and choose Copy.

20.
Open the Services applet, locate the Removable Storage service, right-click it, and stop it. Then minimize the window.

21.
Open a Windows Explorer window and browse to the %systemroot%\ system32\NTMSData directory and delete all the files within it.

22.
Right-click a blank spot in the window and choose Paste to copy in all the files previously restored.

23.
Restore the Services applet to a viewable size, locate the Removable Storage service, right-click the service, and start it. Then close the Services applet.

24.
Open removable media from the Computer Management console and verify that the correct media pools and media information have been restored.

25.
Close Computer Management and log off the server.


Restoring Remote Storage Database

To restore the Remote Storage database after the operating system has been recovered or if the service cannot be started, perform the following steps:

1. | Log on to the Remote Storage server using an account with Local Administrator access.
2. | Click Start, All Programs, Administrative Tools, Remote Storage.
3. | In the Remote Storage window, verify that the service is not running or the correct managed volume information is incorrect.
4. | Back on the desktop, click Start, All Programs, Administrative Tools, Services.
5. | Scroll down in the Services applet and stop the Remote Storage Server and Remote Storage Notification services if either or both of them are running.
6. | Minimize the Services applet window.
7. | Click Start, Run.
8. | Type cmd.exe and click OK to open a command prompt.
9. | In the command prompt, change to the %systemroot%\system32\ RemoteStorage\Engdb folder and delete the files contained in it.
10. | At the command prompt, type rstore.exe c:\system32\RemoteStorage\engdb.bak and press Enter. This command assumes that the operating system has been installed in the default location on the C: drive of the system.
11. | Close the command-prompt window and open the Services applet window that was minimized.
12. | Scroll down to find the Remote Storage Server service and start it.
13. | Close the Services applet and open the Remote Storage console.
14. | In the Remote Storage console, verify that the managed volume information has been successfully restored.
15. | Close the Remote Storage console and all other Windows; then log off the server.

Recovering Data When Reparse Points Are Missing

If a file has been previously migrated to remote storage media and has been replaced on a volume with a reparse or junction point, both the remote storage media and the reparse point are needed to access the migrated data. If a user inadvertently deletes the reparse point, the administrator needs to use standard file and folder recovery processes to restore it. If no backup of the reparse point is available, the migrated data must be accessed using alternate methods.

To recover this data, insert the correct Remote Storage media into the tape device. After the media is loaded, open the Removable Storage service and move the media from the Remote Storage media pool to the backup media pool as necessary. When that is accomplished, open Ntbackup.exe and catalog the media, locate the data, and restore the original file to the desired location. One of the problems is that the data is not saved in the same folder hierarchy as it was originally on the disk, so you will need the filename and version to recover the data.


Achieving 99.999% Uptime Using Windows Server 2003

When the topic of disaster recovery comes up, many people think of the phrase "five nines" or "99.999% uptime." Although understanding this concept is reasonably simple, actually providing five nines for a server or a network can be quite a large and expensive task. Achieving 99.999% uptime means that the server, application, network, or whatever is supposed to have this amount of uptime can only be down for just over five minutes a year. Having such success is quite a claim to make, so administrators should make it with caution and document it, citing explicitly what this service depends on. For example, if a power failure occurs and the battery backups will last only two hours, a dependency for a server could be that if a power outage occurs, it can withstand up to two hours without power.

To provide 99.999% uptime for services available on Windows Server 2003, administrators can build in redundancy and replication on a data, service, server, or site level. Many Windows Server 2003 services outlined in previous chapters in this book, including Cluster Services, network load balancing, the Distributed File System, and the File Replication Service, can provide redundancy at each level described here.

Providing Redundant Domain Services

To provide redundant domain and network services to be able to deliver five nines uptime, administrators can use Windows Server 2003 built-in services and clever designs to meet the particular type of failure or disaster they are planning for. For example, if an organization provides a Web-based Internet application, five nines can be achieved in a single location by deploying the application on a network load-balancing cluster of servers. To provide this same application across separate sites, the organization would need to establish a VPN across the sites so that a single DNS record could be used to access the server from either location.


Summary

Most administrators hate to find themselves trying to recover from a disaster. Without proper planning and testing of backup and recovery procedures, including planning for all the different types of failures, recovering from a failure can take unnecessarily long or might be unachievable. The information provided in Chapter 32 and this chapter can provide an organization with the basic knowledge of what sorts of disasters can occur and how to successfully back up and recover Windows Server 2003 systems.


Best Practices

  • Document backup and recovery procedures.

  • Periodically test the restore procedures to verify accuracy and test the backup media to ensure that data can actually be recovered.

  • Isolate failures before attempting a restore or fixing a problem.

  • Allocate the appropriate hardware devices including servers with enough processing power and disk space to accommodate the restored machines' resources.

  • Host the organization's DNS zones and records using primary DNS servers located either at an Internet service provider (ISP) co-location facility or have a redundant DNS server registered for the domain and located at both the physical locations.

  • Ensure that DNS record-changing procedures are documented and available at the remote site or at an offsite data storage location.

  • Ensure that the host records in the DNS tables for the VPN and Terminal servers are set to low Time to Live values so that DNS changes do not take extended periods to propagate across the Internet.

  • Ensure that network connectivity is established and stable between each site.

  • Replicate file data between the two sites as often as possible.

  • Create at least three copies of backup tape media from a site.

  • Store a copy of all disaster recovery documentation at a secure location but also keep copies in other locations.

  • Define hot spare disks for arrays.

  • Use RAID 1 for system and boot partitions.

  • Understand the dependencies of the applications and services to the operating system to choose whether to rebuild or restore from backup.

  • Do not restore the system state if a server has been cleanly installed and is joined to the original domain.

  • Identify and document special restore requirements for each server.

  • Use a specified subfolder for the restore point such as c:\RestoredData\ to reduce the chance of confusion.


Part X: Problem Solving, Debugging, and Optimization

In This Part

CHAPTER 34 Logging and Debugging

CHAPTER 35 Capacity Analysis and Performance Optimization


Chapter 34. Logging and Debugging

In This Chapter

  • Using the Task Manager for Logging and Debugging

  • Using the Event Viewer

  • System Monitoring

  • Setting Baseline Values

  • Network Monitoring in Windows Server 2003

  • Using the Debugging Tools Available in Windows Server 2003

Up until this chapter, we have focused on planning, designing, implementing, and migrating to a Windows Server 2003 environment. This chapter looks at the logging and debugging tools available for Windows Server 2003 that help an organization identify and isolate problems in its networking environment.

Many of the tools identified in this chapter are similar to those used in a Windows 2000 or even a Windows NT4 environment; however, as with most features of the Windows server family of products, the features and functions of the tools have been improved and expanded in the Windows Server 2003 operating environment.


Using the Task Manager for Logging and Debugging

One of the monitoring tools available in Windows Server 2003 is the Task Manager. It provides an instant view of system resources such as processor activity, process activity, memory usage, and resource consumption. Rather than loading up special monitoring tools and utilities or creating extensive monitoring parameters, you can use the Task Manager to quickly (usually within seconds) and at a glance see the operational state of key network system parameters.

In addition to monitoring processor activity, process activity, memory usage, and resource consumption, the Windows Server 2003 Task Manager provides two additional monitoring components not included in the Task Manager in Windows 2000 server. These two additional components enable you to monitor networking and user activity.

The Windows Server 2003 Task Manager is very useful for an immediate view of system operations. It comes in handy when a user notes slow response time, system problems, or other nondescript problems with the network. With just a quick glance at the Task Manager, you can see whether a server is using all available disk, processor, memory, or networking resources.

There are three methods to launch the Task Manager:

  • Right-click the taskbar and select Task Manager.

  • Press Ctrl+Shift+Esc.

  • Press Ctrl+Alt+Del, and when the Windows Security dialog box launches, click Task Manager.

When the Task Manager loads, you will notice five tabs, as shown in Figure 34.1.

Figure 34.1. The Windows Task Manager.

If you are working on other applications and want to hide the Task Manager, deselect Always on Top in the Task Manager's Options menu. You can also keep the Task Manager off the taskbar when minimized by selecting Options, Hide When Minimized. The following sections provide a closer look at how helpful these components can be.

Monitoring Applications

The first tab on the Task Manager is the Applications tab. The default view is the Details view, but you can change the view to large or small icons by selecting View, Large Icons or View, Small Icons, respectively.

The application view provides a list of tasks on the left pane and the status of the corresponding applications on the right pane. The status enables you to determine whether an application is running and allows you to terminate an application that is not responding or that you determine is in trouble or is causing trouble for your server. To stop such an application, highlight the particular application and click End Task at the bottom of the Task Manager. You can also switch to another application if you have several applications running. To do so, highlight the program and click Switch To at the bottom of the Task Manager.

Monitoring Processes

The second Task Manager tab is the Processes tab. It provides a list of running processes on the server. It also measures the performance in simple data format. This information includes CPU percent used, memory allocated to each process, and username used in initiating a process, which includes system, local, and network services.

If the initial analysis of the process on your server takes up too much CPU percentage or uses too many memory resources, thereby hindering server performance, you can sort the processes by clicking the CPU or Mem Usage column header. The processes are then sorted in order of usage. This way, you can tell which one is slowing down performance on your server. You can terminate a process by selecting the process and clicking the End Process button.

Tip

A command-line tool located in the Windows Server 2003 Resource Kit called the Process Resource Monitor (PMon) can also be used to monitor system and application processes.

Several other performance or process measures can be removed or added to the processes view. They include PID (process identifier), CPU time, virtual memory size, session ID, page faults, and so on. To add these measures, select View, Select Columns to open the Select Column property page. Here, you can add process counters to or remove them from the process list.

Monitoring Performance

The Performance tab allows you to view the CPU and page file usage in graphical form. This information is especially useful when you need a quick view of a performance bottleneck.

The Performance tab makes it possible to graph a percentage of processor time in Kernel mode. To show this, select View, Show Kernel Times. The kernel time is represented by the red line in the graph. The kernel time is the measure of time that applications are using operating system services. The other processor time is known as User mode. User mode processor time is spent in threads that are spawned by applications on the system.

If your server has multiple CPU processors installed, you can view multiple CPU graphs at a time by selecting View, CPU History.

Monitoring Network Performance

The Networking tab provides a measurement of the network traffic for the connections on the local server in graphical form, as shown in Figure 34.2.

Figure 34.2. The Networking tab on the Windows Task Manager.

[View full size image]

For a multiple network connectionwhether it is a dial-up LAN connection, WAN connection, VPN connection, or the likethe Networking tab displays a graphical comparison of the traffic for each connection. It provides a quick overview of the adapter, network utilization, link speed, and state of your connection.

To show a visible line on the graph for network traffic on any interface, the view automatically scales to magnify the view of traffic versus available bandwidth. The graph scales from 0% to 100% if the Auto Scale option is not enabled. The greater the percentage shown on the graph, the less is the magnified view of the current traffic. To auto-scale and capture network traffic, select Options, Auto Scale.

The Networking tab serves as a quick reference for measuring network bandwidth. It can be used to quickly determine whether a network interface has excessive traffic or to find out the communications status of a network connection.

You can add more column headings by selecting View, Select Columns. Various network measures can be added or removed; they include Bytes Throughput, Bytes Sent/Interval, Unicasts Sent and Received, and so on.

Tip

If you suspect a possible network server problem, launch the Task Manager and quickly glance at the CPU utilization, memory available, process utilization, and network utilization information. When the utilization of any or all of these items exceeds 60% to 70%, there may be a bottleneck or overutilization of the resource. However, if all the utilization information shows demand being less than 5%, the problem is probably not related to server operations.

Monitoring User Activity

The Users tab displays a list of users who can access the server, session status, and names. The following five columns are available on the Users tab:

  • User Shows the users logged on to the server. To obtain a detailed view showing from which computer the user is connected, highlight the user and select Options, Show Full Account Name.

  • ID Displays the numeric ID that identifies the session on the server.

  • Client Name Specifies the name of the client computer using the session, if applicable.

  • Status Displays the current status of a session. Sessions can be either Active or Disconnected.

  • Session Displays the session names on the server.


Using the Event Viewer

The Event Viewer is the next tool to use when debugging, problem-solving, or logging information to resolve a problem with a network server. The Event Viewer, shown in Figure 34.3, is a built-in Windows Server 2003 tool that is used for error analysis and diagnostics.

Figure 34.3. The Event Viewer in Windows Server 2003.

[View full size image]

Microsoft defines an event as any significant occurrence in the operating system or an application that requires tracking of the information. An event is not always negative because a successful logon to the network, a successful transfer of messages, or replication of data can also generate an event in Windows. It is important to sift through the events to determine which are informational events and which are critical events that require attention.

When server failures occur, the Event Viewer is one of the first places to check for information. The Event Viewer can be used to monitor, track, view, and audit security of your server and network. It is used to track information of both hardware and software contained in your server. The information provided in the Event Viewer can be a good starting point to identify and track down a root cause to system errors.

Note

A Windows Server 2003 system has event logs for system, security, and applications. On a domain controller, the Event Viewer also includes directory services, domain name system (DNS), and File Replication Services (FRS) logs. Depending on other applications loaded or running on a server, additional event logs may be added to the managed logs of the Event Viewer utility.

You can access the Event Viewer through the Administrative Tools menu or by right-clicking the My Computer icon on the desktop and selecting Manage. You can also launch the Event Viewer by running the Microsoft Management Console (File, Run, mmc.exe) or through a command line by running eventvwr.msc.

Getting the Most out of the Event Viewer

As noted previously, events can range in importance from simple informational data to serious or catastrophic events such as transport protocol or major system failures. The primary types of events include success audit, failure audit, informational, warning, and error. An icon in Event Viewer identifies the severity of each type of event.

The console tree on the left pane of the Event Viewer window lists the logs available to view, and the details pane on the right side of the window displays the events. Click a log to view the events associated with it on the details pane. When you're viewing a log, the Event Viewer displays the current information for the log. While you view the log, the information is not updated unless you refresh the Event Viewer. If you switch to another log and then return to the previous log, the previous log is automatically updated.

Each log has common properties associated with its events:

  • Type This property defines the severity of the event. An icon appears next to each type of event. It helps to quickly identify whether the event is informational, a warning, or an error.

  • Date This property indicates the date that the event occurred. You can sort events by date by clicking the Date column. This information is particularly helpful in tracing back an incident that occurred in the past, such as a hardware upgrade before your server started experiencing problems.

  • Time This property indicates the time that the event occurred. It can be used the same as the date.

  • Source This property identifies the source of the event, which can be an application, remote access, a service, and so on. The source is very useful in determining what caused the event.

  • Category This property determines the category of an event. An example is the Security category, which includes Logon/Logoff, System, Object Access, and others.

  • Event Each event has an associated Event ID, which is a numeral generated by the source and is unique to each event. You can use the Event ID on the Microsoft Support Web site (http://www.microsoft.com/technet/) to find topics and solutions related to an event on your server.

  • User This property identifies the user that caused the event to occur. User does not necessarily mean the person logged on to the server. Examples of user events in the Security log are System, Local Service, Network Service, and so on.

  • Computer This property identifies the computer that caused the event to occur.

To view more comprehensive details of events, click the log event in the console tree and double-click the event to view in the details pane (or select it and press Enter). The Event Viewer opens a property page showing the properties of the event, as shown in the sample in Figure 34.4. The top portion includes general information about the event, such as date, time, user, source, and so on. The Description field gives a detailed description of the event and contains a URL to Microsoft. If you click the link, information relating to the event is sent to Microsoft over the Internet in the form of a query, which will help you get more detailed information. To view details about the previous or next event, click the up or down arrow. To copy the details of an event to the Clipboard, click the Document button. The bottom part of the property page shows additional data included with the event. The Data field includes characters in bytes (hexadecimal) or words format. It displays by default as bytes, but you can switch the characters to words by clicking the Words radio button.

Figure 34.4. Detailed event properties.

You can search for a specific event by highlighting the log and selecting View, Find. In the resulting dialog box, you can search based on user, computer, event source, information, success audit, or any property or value stored in the event log. It is particularly useful to search for specific events, states in time, or other information when you have a large log and need to narrow in on information about a specific event or point in time.

Viewing Logs on Remote Servers

Event Viewer enables you to connect to other computers on your network. To connect to another computer from the console tree, right-click Event Viewer (Local) and click Connect to Another Computer. Select Another Computer and then enter the name of the computer or browse to it and click OK. You must be logged in as an administrator or be a member of the Administrators group to view event logs on a remote computer. If the new computer requires a low-speed connection, right-click the log to be viewed and then click Properties. On the General tab, click Using a Low-Speed Connection.

Event Filtering

By default, the Event Viewer displays all events for a selected log. Filtering is very useful when it becomes necessary to narrow down the view. It is helpful to be able to filter the view so that the Event Viewer shows events that meet specific criteria. To use a filter, select the log to be filtered and then select View, Filter. This will result in the property page shown in Figure 34.5.

Figure 34.5. Filtering for Event Viewer events.

Tip

Event Comb (EventCombMT), located in the Windows Server 2003 Resource Kit, can assist you with the task of combing through multiple event logs on domain controllers. More specifically, you can check and diagnose replication by using the utility to search for particular EventIDs related to replication. Another similar tool that can be used in conjunction with EventCombMT is the Checkrepl.vbs script, which can monitor replication for a specific domain controller.

Events can be filtered based on different fields. It is possible to filter based on event source, category, and date range. If you suspect you have an application or service causing a server malfunction, it is helpful to filter based on event source. From the Event Source pull-down menu on the System Properties page, select the category or select All (default) to filter all event sources. To filter events based on date, specify the date range and then enter the From and To fields based on the date range you want to view information.

To return to the default view, click Restore Defaults and click OK. Choose View, All Records to remove the filter and view all events in the log.

Note

Filtering changes only the view and has nothing to do with the actual contents of the log. All events are continuously logged whether or not filtering is turned on. If a log file from a filtered view is archived, all records are saved, even if you select a text format or comma-delimited text format file.

Archiving Events

Occasionally, you need to archive an event log. Archiving a log copies the contents of the log to a file. Archiving is useful in creating benchmark records for the baseline of a server, or for storing a copy of the log that can be viewed or accessed elsewhere. When an event log is archived, it is saved in one of three forms:

  • Comma-delimited text file (.csv) This format allows the information to be used in a program such as Excel.

  • Text-file format (.txt) This format allows the information to be used in a program such as a word processing program.

  • Log file (.evt) This format allows the archived log to be viewed again in the Event Viewer.

The event description is saved in all archived logs. The sequence of data generated within each record is in this order: date, time, source, type, category, event, user, computer, and description. To archive, right-click the log to be archived and click Save Log File As. In the File Name field of the resulting property page, type in a name for the archived log file, choose a file type from the file format options of .csv, .txt, or .evt, and then click Save.

Note

You must be a member of the Backup Operators group at the minimum to archive an event log.

Logs archived in log-file format (.evt) can be reopened using the Event Viewer utility. Logs saved in log-file format retain the binary data for each event recorded. Event logs, by default, are stored on the server from which the Event Viewer utility is being run, but data can be archived to a remote server by simply providing a UNC path (such as \\servername\ share\) when entering a filename.

Logs archived in comma-delimited (.csv) or text (.txt) format can be reopened in other programs such as Microsoft Word or Microsoft Excel. Logs archived in text or commadelimited format do not retain the binary data.

Tip

By periodically archiving security logs to a central location on your network and then reviewing them against local security logs, you can see differences more clearly between logs that can help you proactively identify unauthorized activity on a server.

Customizing the Event Log

Each event log has a property associated with it. This property can be used to customize each of the event logs. The property defines the general characteristics of the log in the Event Viewer, such as the appearance of the log in the Event Viewer, the log size, and what should happen when the maximum log size is reached.

To customize the event log, access the properties of the particular log by highlighting the log and selecting Action, Properties. Alternatively, you can right-click the log and select Properties to display the General tab of its property page, as shown in Figure 34.6.

Figure 34.6. Selecting properties for the event log.

The Log Size section specifies the maximum size of the log and the subsequent actions to be taken when the maximum log size limit is reached. The three options are

  • Overwrite Events as Needed

  • Overwrite Events Older Than X Days

  • Do Not Overwrite Events

If you select the Do Not Overwrite Events option, Windows Server 2003 will discontinue to log events when it fills up. Although Windows Server 2003 will notify you when the log is full, you will need to monitor and manually clear the log periodically so that new events can be tracked and stored in the log file. Log file sizes must be specified in multiples of 64KB. If a value is not in multiples of 64KB, the Event Viewer will automatically set the log file size to a multiple of 64KB.

When you need to clear the eventfor example, when the log is fullclick Clear Log in the lower right of the property page. If you need to reset the logging information to defaults, click Restore Defaults to reset the log-tracking information.

If a remote server is being monitored and is connected using a low-speed connection, check the Using a Low-Speed Connection box. Using a low-speed connection prevents the Event Viewer from downloading all event data before it is requested. This feature is useful when you're working with logs on a remote server with a slow connection such as dial-up or over a slow WAN connection.

Understanding the Security Log

Logging an accurate and wide range of security events in the Event Viewer requires an understanding of auditing in Windows Server 2003. It is important to know that events are not audited by default. Through auditing, which is enabled in the local security policy for a local server, domain controller security policy for a domain controller machine, or an Active Directory (AD) Group Policy Object (GPO) for a domain, you can track Windows Server 2003 security events. It is possible to specify that an audit entry be written to the security event log whenever certain actions are carried out or an object (such as a file or printer) in AD is accessed. The audit entry shows the action carried out, the user responsible for the action, and the date and time of the action. Successful and failed attempts at actions can be audited so that the audit trail shows the user or users who performed certain actions on the network or user or users who attempted to perform certain actions that are not permitted.

Auditing System Events Through Group Policies

For a domain, the types of system events audited through Group Policies can be specified by navigating to Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy in the Group Policy Object Editor and double-clicking an event category that needs to be changed in the details pane. If you're defining the audit policy settings for an event category for the first time, check the Define These Policy Settings box. Then do one or both of the following and click OK:

  • To audit successful attempts, check the Success box.

  • To audit unsuccessful attempts, check the Failure box.

The default auditing policy setting for domain controllers is No Auditing. This means that even if auditing is enabled for a domain, it does not necessarily imply that auditing has been enabled for the domain controller because domain controllers do not inherit auditing policy locally. To enable auditing on domain controllers, use the domain controller security policy.

The following examples describe how to set up auditing for some objects on a domain, site, or organizational unit (OU) using the Group Policy Object Editor (Computer Configuration\Windows Settings\Security Settings):

  • Registry keys Highlight the Registry in the console pane, right-click Registry, and then click Add Key. Browse to locate the key you want to edit and click OK. To modify a Registry key that has already been added to a GPO, right-click the Registry key, click Properties, and click Edit Security.

  • System services Highlight the particular service you want. Right-click the service and select Properties. If it is not already selected, check the Define This Policy Setting box and then select the appropriate setting. Then click Edit Security.

  • Files or folders Right-click File System and then click Add File. Browse to the specific file and click OK. To modify auditing on a file or folder already in this GPO, in the details pane, right-click the file or folder and then click Edit Security.

If security logging is crucial in the organization, you can choose to shut down the server immediately if logging is unable to save a security event to the log file. This security policy can be located in Computer Configuration\Windows Settings\Security Settings\ Local Policies\Security options. Enabling this security setting causes the system to stop if a security audit cannot be logged.

A typical reason for an event failing to be logged is that the security audit log is full and the retention method specified in the log general properties is Do Not Overwrite Events. When this situation arises, the following stop error appears:

STOP: C0000244 {Audit Failed}.
An attempt to generate a security audit failed.

To bring the system back online after an automatic security eventinduced shutdown, turn the server back on, log in as an administrator, and clear or archive the log.

Note

In severe situations, an organization may choose to have servers automatically shut down when a security breach or event occurs. However, it is important to note that a server shutdown in the middle of the day can affect all users on the network who were connected to the shut-down server, so care must be taken in selecting the applicable security policy and automated process appropriate for the organization. Also, if the sole purpose of the attack is to deny service, it will be a success if the server shuts down automatically.


System Monitoring

System monitoring is a crucial aspect of the overall availability and health of the network. For maximum uptime, a process needs to be put in place to monitor and analyze system performance. This invariably provides a means of quickly comparing system performances at varying instances in time, and detecting and potentially preventing a catastrophic incident before it causes system downtime.

The System Monitor takes a snapshot of system performance characteristics at periodic intervals and displays the information in graphical format similar to that shown in Figure 34.7. The information can then be used to monitor the behavior of the system, predict future resource requirements, measure the load on system components, and also trigger an alert to inform you of potential failures of system components.

Figure 34.7. System monitoring with the Performance console.

[View full size image]

Windows Server 2003 monitors or analyzes memory, storage, networks, and other system resources and operations. It is not good enough to just monitor memory usage itself without knowing the components or functionality of software that is using the memory. For example, if 128MB of memory is used over a specified period of time, rather than knowing that 128MB of memory was used, it is more valuable knowing what used the memory and why that much was used.

Performance Monitoring Tools

Windows Server 2003 comes with two tools for performance monitoring: System Monitor and Performance Logs and Alerts. These two tools together provide performance analysis and information that can be used for bottleneck and troubleshooting analysis.

Terms Used in the Performance Monitoring Tools

Defining some terms used in performance monitoring will help clarify the function of the System Monitor and how it ties in to software and system functionality. The three components noted in the System Monitor are as follows:

  • Object Components contained in a system are grouped into objects. Objects are grouped according to system functionality or association within the system. Objects can represent logical entities such as memory or a physical mechanism such as a hard disk drive. The number of objects available in a system depends on the configuration. For example, if Microsoft Exchange server is installed on a server, some objects pertaining to Microsoft Exchange would be available.

  • Counter Counters are subsets of objects. Counters typically provide more detailed information for an object, such as queue length or throughput for an object. The System Monitor can collect data through the counters, with data being collected and displayed in graphical or text log formats.

  • Instances If a server has more than one similar object, each one is considered an instance. For example, a server with multiple processors has individual counters for each instance of the processor. Counters with multiple instances also have an instance for the combined data collected for the instances.

The Performance Console

You can open the Performance console from the Administrative Tools by selecting Start, Programs, Administrative Tools, Performance. You can also open it from a command line by typing Perfmon.msc. When a new Performance console is started, it loads a blank system monitor graph into the console. The Performance console contains two utilities: System Monitor and Performance Logs and Alerts.

The System Monitor

The System Monitor provides an interface to allow the analysis of system data, research performance, and bottlenecks. The System Monitor displays performance counter output in graph, histogram (bar chart), and report format.

The histogram and graph view can be used to view multiple counters at the same time, as shown in Figure 34.8. However, each data point displays only a single value that is independent of its object. The report view is better for displaying multiple values. Data sources can be obtained by clicking the View Current Activity button on the button bar. On the other hand, clicking View Log Data displays data from completed or running logs.

Figure 34.8. The graph view of the Performance console.

[View full size image]

The System Monitor is ideal for diagnostics and short-term views of performance output. Before counters can be displayed, they have to be added. The counters can be added simply by using the button bar. The Counter button on the button bar includes Add, Delete, and Highlight. You can use the Add Counter button to add new counters to be displayed. The Delete Counter button removes unwanted counters from the display. The Highlight button is helpful for highlighting a particular counter of interest; a counter is highlighted with a white or black color around the counter. The Highlight button cannot be used with Report view.

Tip

You can display the function of a button in the button bar by placing the mouse cursor on the button.

When the Add Counter button is selected, a dialog box similar to the one shown in Figure 34.9 appears. The top section of this property page allows you to either choose the server being worked on or connect to a different server on the network. The System Monitor allows you to connect to a remote computer and be able to monitor system performance of the server. This process is referred to as remote monitoring.

Figure 34.9. Adding a counter to the Performance console.

Tip

If a server stops responding, run the System Monitor from another computer to monitor the troubled server.

Performance objects and their associated counters can be added to the system monitoring tool to expand the level of detail being collected for the performance of a system. Select a counter and click the Add button to add it to the display. In the instance list box, the first value, Total, allows you to add all the instance values and report them in the display. When you need to understand what a counter does or learn more about it, select the counter and click the Explain button.

You can have more than one monitoring setup in more than one Performance console. The more counters and monitors you set up, the more your system's resources are used to support the system monitoring tool operations. If you need to monitor a large number of system monitors and counters, it is better to redirect the output data to a log file and then read that log file in the display.

Back on the System Monitor display, you can update displays by clicking the Clear Display button. Clicking the Freeze Display button or pressing Ctrl+F freezes displays, which suspends data collection. Data collection can be resumed by pressing Ctrl+F or clicking the Freeze Display button again. Click the Update Data button to display an updated data analysis.

It is also possible to export and import a display by using the Cut and Paste buttons. For example, a display can be saved to the Clipboard and then imported into another instance of the System Monitor. This is commonly done to take system information and view or analyze that information on a different system rather than performing analysis on a production server.

The Properties page has five tabs: General, Source, Data, Graph, and Appearance. Generally, the Properties page gives access to settings that control the graph grid, color, style of display data, and so on. Data can be saved from the monitor in different ways. The easiest way to retain the display features when saved is to save the control as an HTML file. You can match lines in the display with their respective counters by selecting the color that matches the line in the display.

The System Monitor enables you to save log files in comma-separated (csv) or tab-separated (tsv) format, which you can then analyze by using third-party tools such as Seagate Crystal Reports. Alternatively, a comma-separated or tab-separated file can be imported into a spreadsheet or database application such as Microsoft Excel or Access. Windows Server 2003 also allows you to collect data in SQL database format, which is useful for performance analysis at an enterprise level rather than a per-server basis. Reports displayed in Excel can help you better understand the data as well as provide reports to management. After the log file is saved in .csv format, the file can be opened using Microsoft Excel.

Performance Logs and Alerts

The Performance Logs and Alerts utility has two types of performance-related logs: Counter logs and Trace logs. These logs are useful for advanced performance analysis and data logging over a period of time. The utility also comes with an alerting mechanism used to trigger alerts.

Some improvements have been added in Windows Server 2003 performance analyses that were not available in previous versions of Windows. One is the ability to run log collections under different accounts. For example, if you need to log data from a remote server that requires administrator privileges, the system will allow you to specify an account with the necessary permissions using the Run As feature. Another improvement to Windows Server 2003 is the ability to support log files greater than 1GB in size. Performance data can also be appended to an existing log file because of the new log file format.

Note

Data collection occurs regardless of whether a user is logged on to the server being monitored because logging runs as a service.

The three components to Performance Logs and Alerts are as follows:

  • Trace logs Trace logs collect event traces. They provide measurement of performance associated with events related to system and nonsystem providers. Data is sent to the logs immediately as an event occurs and is measured continuously in a stream from the beginning of an event to its end. This is different from the way the System Monitor measures data. The System Monitor measures data using sampling.

  • Counter logs Counter logs record sampled data about system services, threads, and hardware resources based on objects in the System Monitor. This utility uses counters the same way the System Monitor does.

  • Alerts Alerts provide a function used to define a counter value that will trigger an alert. When an alert is triggered, the alert function can be set up to perform some action, such as sending a network message, executing a program, or starting a log. Alerts are useful for notification purposes in times of emergency (unusual activity that does not occur often) such as bandwidth saturation to or from a network interface card (NIC) hosting a business-critical application. Alerts provide notification when a particular resource performance value exceeds or drops below a threshold, baseline, or set value.

Configuring Trace Logs

Configuring and enabling Trace logs to monitor the activities of an application or environment variable is simply a matter of creating a Trace log filename and enabling logging.

To create a trace log, do the following:

1. | Launch the Performance monitoring tool (Start, Programs, Administrative Tools, Performance).
2. | Double-click Performance Logs and Alerts and click once on the Trace logs.
3. | Right-click a blank area of the details pane on the right of the window and click New Log Settings.
4. | In the Name field, type the name of the Trace log you want to create and then click OK.

For a list of installed providers and their status (enabled or not), click Provider Status in the General tab. By default, the Nonsystem Providers option is selected to keep trace logging overhead to a minimum. Click Events Logged by System Provider and check the boxes as appropriate to define events for logging.

On the Log File tab, you can configure the log to be circular, so that when the log file reaches a predetermined size, it will be overwritten.

Common Log File System

New to Windows 2003 R2 is Common Log File System (CLFS). This architecture allows both OEM and custom applications to use common logging structures. A first for Windows, CLFS can create log files with multiple streams of data from multiple sources. It is the first native multiplexing log system. This brings native root cause analysis closer to the operating system instead of relying on expensive third-party tools. CLFS also allows generic policy-based management for uniformity across the enterprise.

CLFS will be integrated with emerging products, including Microsoft Exchange 12 and Windows Clustering. In a clustered environment it allows all member servers to maintain a single, shared log. Possibly its most important feature, CLFS is designed for high performance and will allow for MOM 2005 to manage servers "agentless" without the performance overhead penalty currently incurred.


Setting Baseline Values

A baseline is a performance level that can be used as a starting point to compare against future network performance operations. When a server is first monitored, there is very little to compare the statistics against. After a baseline is created, information can be gathered at any time in the future and compared against the baseline. The difference between the current statistics and the baseline statistics is the variance caused by system load, application processing, or system performance contention.

To be able to set a baseline value, you need to gather a normal set of statistics on each system that will eventually be monitored or managed in the future. Baselines should be created for normal and stressed times. The workload on a machine at night when there are fewer users connected to it provides a poor baseline to compare real-time data in the middle of the day. Information sampled in the middle of the day should be compared with a baseline of information collected at around the same time of day during normal load prior to the sample comparison.

Creating baselines should be an ongoing process. If an application or a new service is added to a server, a new baseline should be created so that any future comparisons can be made with a baseline with the most current status of system performance.

Reducing Performance Monitoring Overhead

Performance monitoring uses system resources that can affect the performance of a system as well as affect the data being collected. To ensure that performance monitoring and analyzing do not affect the machines being monitored themselves, you need to decrease the impact of performance monitoring. Some steps can be taken to ensure that performance monitoring overhead is kept to a minimum on the server being monitored to create as accurate of an analysis on a system as possible:

  • Use a remote server to monitor the target server. Servers can actually be dedicated to monitoring several remote servers. Although this might also lead to an increase in network bandwidth, at least the monitoring and tracking of information do not drastically degrade CPU or disk I/O as if the monitoring tool were actually running on the server being monitored.

  • Consider reducing the frequency of the data collection interval because more frequent collection can increase overhead on the server.

  • Avoid using too many counters. Some counters are costly in terms of taxing a server for system resources and can increase system overhead. Monitoring several activities at one time also becomes difficult.

  • Use logs instead of displaying graphs. The logs can then be imported into a database or report. Logs can be saved on hard disks not being monitored or analyzed.

Important Objects to Monitor

The numbers of system and application components, services, and threads to measure in Windows Server 2003 are so extensive that it is impossible to monitor thousands of processor, print queue, network, or storage usage statistics. Defining the roles a server plays in a network environment helps to narrow down what needs to be measured. Servers could be defined and categorized based on the function of the server, such as application server, file and print server, or services server such as DNS, domain controller, and so on.

Because servers perform different roles, and hence have different functions, it makes sense to monitor the essential performance objects. This helps prevent the server from being overwhelmed from the monitoring of unnecessary objects for measurement or analysis. Overall, four major areas demand the most concern: memory, processor, disk subsystem, and network subsystem. They all tie into the roles the server plays.

The following list describes objects to monitor based on the roles played by the server:

  • Domain controller Because the DC provides authentication, stores the Active Directory database, holds schema objects, and so on, it receives many requests. To be able to process all these requests, it uses up a lot of CPU resources, disks, memory, and networks. Consider monitoring memory, CPU, system, network segment, network interface, and protocol objects such as TCP, UDP, NBT, NetBIOS, and NetBEUI. Also worth monitoring are the Active Directory NTDS service and site server LDAP service objects. DNS and WINS also have applicable objects to be measured.

  • File and Print server The print servers that process intensive graphics jobs can utilize extensive resources of system CPU cycles very quickly. The file server takes up a lot of storage space. Monitor the PrintQueue object to track print spooling data. Also monitor CPU, memory, network segment, and logical and physical disks for both file and print data collection.

  • Message Collaboration server A messaging server such as a Microsoft Exchange server uses a lot of CPU, disk, and memory resources. Monitor memory collection, cache, processor, system, and logical and physical disks. Some Exchange objects are added to the list of objects after Exchange is installed, such as message queue length or name resolution response time.

  • Web server A Web server is usually far less disk intensive and more dependent on processing performance or memory space to cache Web pages and page requests. Consider monitoring the cache, network interface, processor, and memory usage.

  • Database server Database servers such as Microsoft SQL Server can use a lot of CPU and disk resources. Database servers such as Microsoft SQL Server use an extensive amount of memory to cache tables and data, so RAM usage and query response times should be monitored. Monitoring objects such as system, processor, logical disk, and physical disk is helpful for overall system performance operations.


Network Monitoring in Windows Server 2003

Windows Server 2003 comes with a tool called Network Monitor that is used to perform network communications traffic analysis. Network Monitor, also known as Netmon, provides network utilization statistics and packet traffic as well as captures frames for analysis.

Note

In addition to the Network Monitor, as well as some of the tools already mentioned, such as EventCombMT and Checkrepl.vbs, There are other utilities in the Windows Server 2003 Resource Kit that can assist in analyzing and diagnosing network-related functions. Two tools, called the Link Check Wizard and Chknic, should be added to your arsenal especially for troubleshooting purposes.

Data is transferred all the time from one point to another in the form of network traffic that is divided into frames. A frame contains information such as the address of the machine to which it is destined, the source address, and protocols that exist within the frame. Besides having bottlenecks on the server, bottlenecks can also occur on the network when it is overwhelmed. For example, a network adapter can fail and flood the network with invalid network transmissions that can slow down the rate of data transfer between other devices on the network. When the network becomes slow, the network can be said to have reduced available network bandwidth.

Netmon can be viewed as both a network troubleshooting tool and a packet analysis tool. The version of Netmon that comes with Windows Server 2003 allows only the capture of frames sent to and from your local server. The full-featured version of Network Monitor that provides enterprisewide network monitoring, allowing network traffic to be monitored or analyzed to and from any computer in the network, can be found in the Microsoft Systems Management Server (SMS).

Understanding How Netmon Works

All computers on a network segment can receive and send frames within their segments. Network adapters on these computers process only frames meant for them; they discard all frames not addressed to them. These network adapters also retain broadcast and multicast frames.

After Netmon is installed, you can capture to a file all the frames sent to or retained by the adapter on which Netmon was installed. These captured frames can then be used for later analysis. It is possible to set up a capture filter so that only certain frames are captured. Frames can be filtered based on criteria such as source address, destination address, type of information captured, or the like. Capture triggers can also be set up to initiate certain actions such as starting a program, starting a capture, or ending a capture based on a specific event occurring on the network.

Installing Netmon

Before Netmon can be used, it must be installed from the Control Panel. To install Netmon, follow these steps:

1. | Open the Control Panel.
2. | Click Add or Remove Programs.
3. | Click Add/Remove Windows Components to open the Windows Components Wizard.
4. | Select Management and Monitoring Tools and click Details.
5. | Check Network Monitor Tools and then click OK.
6. | Click Next and if prompted for additional files, insert the installation CD.
7. | Click Finish at the end of the installation.

Go to the Administrative Tools and select Network Monitor to open the utility. After Netmon is loaded, you can capture all frames sent to or retained by the network adapter of the machine on which it is installed. These captured frames can then be saved or viewed for further analysis.

The Netmon application, shown in Figure 34.10, provides several types of information. The capture window display is divided into three parts: system statistics, network and captured statistics, and station statistics.

Figure 34.10. The Network Monitor console.

[View full size image]

In the upper-left pane is the Netmon graph. It shows current activities on the network in a horizontal bar-like fashion. The Total Statistics pane located in the upper right displays the total network activity detected since a capture began. The Session pane located in the lower left shows the established session between two nodes. The Station Statistics pane located in the bottom pane shows statistics about frames sent and received on a per-node basis. The Station Statistics pane has several fields such as Frames and Bytes Sent and Received, Directed Frames Sent, Multicasts Sent, Broadcasts Sent, and the network (local server) responsible for the traffic. The Station Statistics pane can also help you identify the largest broadcaster in a network; to do so, right-click the Broadcasts Sent column and then click the Sort button.

Capturing Frames Within Netmon

Before you start capturing frames, make sure to select a network adapter from the Capture menu (typically the primary network adapter of the system being monitored). Also select buffer settings from the Capture menu. To begin capturing, click the Start Capture button (it looks like a play button on a cassette tape recorder). Alternatively, press the F10 key. Capture will proceed to fill the memory with frames until it is full, so capture only the frames needed and over a short duration of time. This decreases the effect that Network Monitor will have on the performance of the server being monitored. To stop, pause, or display captured data from the Capture menu, simply select Stop, Pause, or Display Captured Data. You also can stop and display the capture by clicking Stop and View. To save a captured frame for future analysis, select File, Save As and specify a path and filename to store the captured frame.

To set a capture trigger, select Capture, Trigger to open a property page similar to the one shown in Figure 34.11. On the Capture Trigger property page, select Pattern Match to initiate a trigger action when a specific hexadecimal or ASCII string appears in a frame. In the Pattern text box, type a string and specify ASCII or Hex. It is possible to have an action occur whenever there is a trigger. To do so, select Audible Signal Only to have the machine beep, select Stop Capture to stop the capture, or check Execute Command Line and specify the command or program that runs when a trigger occurs.

Figure 34.11. The Capture Trigger property page.

To initiate a trigger based on the size of the buffer, select Buffer Space and then choose the percentage. It is also possible to have an action occur whenever there is a trigger. To initiate a trigger when a specific pattern in a frame is detected, select Buffer Space Then Pattern Match and specify the percentage and pattern needed.

Using the Capture Filter

Filtering can help reduce the amount of data being reviewed and analyzed. A capture filter can be specified based on addresses, protocols, and frame data patterns. To set up a filter, select File, Capture, Filter.

To capture data based on specified frame data patterns, double-click the AND (Pattern Matches) line in the Capture Filter decision tree and then specify the hexadecimal or ASCII data pattern that captured frames should match.

To specify captured filters based on address pairs similar to the ones shown in Figure 34.12, double-click the AND (Address Pairs) line in the decision tree or double-click the address pair to edit. In the Address Expression dialog box, specify address pair properties, and then click OK.

Figure 34.12. Selecting address pairs on the capture filter.

Captured data can be displayed by selecting File, Capture, Display Captured Data. You'll see a summary page similar to the one shown in Figure 34.13. The captured data displays the frame, time duration, source MAC address, destination MAC address, protocol, and so on.

Figure 34.13. The Capture summary page.

[View full size image]

Note

In a capture filter, the EXCLUDE statement takes precedence over the INCLUDE statement regardless of the order in which statements appear in the Capture Filter property page. If a filter contains both the INCLUDE and EXCLUDE statements, the frame is discarded if it meets the criteria specified in the EXCLUDE statement. Network Monitor does not check whether the frame meets the INCLUDE statement criteria.


Using the Debugging Tools Available in Windows Server 2003

Several useful tools are available in Windows Server 2003 for troubleshooting and diagnosing various problems ranging from TCP/IP connection issues to verification and maintenance issues. These tools also make it much easier for IT professionals, allowing IT personnel to focus on business improvement tasks and functions, not on simply running specific tools in the networking environment.

TCP/IP Tools

TCP/IP forms the backbone of communication and transportation in Windows Server 2003. Before you can communicate between machines, TCP/IP must be configured. In Windows Server 2003, Microsoft decided to make TCP/IP install by default during the OS installation and also made it impossible to add or remove TCP/IP through the GUI.

Microsoft also added four new parameters (-R, -S, -4, -6) to some of the TCP/IP utilities in Windows Server 2003 that were not available in previous versions of Windows; these parameters will be discussed next.

If a TCP/IP connection fails, you need to determine the cause or point of failure. Windows Server 2003 includes some dependable and useful tools that can be used to troubleshoot connections and verify connectivity. The tools described in the following eight sections are very useful for debugging TCP/IP connectivity problems.

PING

PING means Packet Internet Groper. It is used to send an Internet Control Message Protocol (ICMP) echo request and echo reply to verify the availability of a local or remote machine. You can think of PING as a utility that sends a message to another machine asking "Are you still there?" By default, in Windows Server 2003, PING sends out four ICMP packages and waits for responses back in one second. However, the number of packages sent or time to wait for responses can be changed through the options available for PING.

Besides verifying the availability of a remote machine, PING can help determine a name resolution problem.

To use PING, go to a command prompt and type PING Targetname, as shown in Figure 34.14. Different parameters can be used with PING. To display them, type PING /? or PING (without parameters).

Figure 34.14. A PING command in a command-prompt window.

[View full size image]

The parameters for the PING command are as follows:

-4 Specifies that IPv4 is used to ping. This parameter is not required to identify the target host with an IPv4 address. It is required only to identify the target host by name.

-6 Specifies that IPv6 is used to ping. Just like 4, this parameter is not required to identify the target host with an IPv6 address. It is required only to identify the target host by name.

-a Resolves the IP address to the hostname. The hostname of the target machine is displayed if this command is successful.

-f Requests that echo back messages are sent with the Don't Fragment flag in packets. This parameter is available only in IPv4.

-i ttl Increases the timeout on slow connections. The parameter also sets the value of the Time to Live (TTL). The maximum value is 255.

-j HostList Routes packets using the host list, which is a series of IP addresses separated by spaces. The host can be separated by intermediate gateways (loose source route).

-k HostList Similar to j but hosts cannot be separated by intermediate gateways (strict source route).

-l size Specifies the length of packets in bytes. The default is 32. The maximum size is 65,527.

-n count Specifies the number of packets sent. The default is 4.

-r count Specifies the route of outgoing and incoming packets. It is possible to specify a count that is equal to or greater than the number of hops between the source and destination. The count can be between 1 and 9 only.

-R Specifies that the roundtrip path is traced (available on IPv6 only).

-S count Sets the time stamp for the number of hops specified by count. The count must be between 1 and 4.

-S SrcAddr Specifies the source address to use (available on IPv6 only).

-t Specifies that PING should continue sending packets to the destination until interrupted. To stop and display statistics, press Ctrl+Break. To stop and quit PING, press Ctrl+C.

-v TOS Specifies the value of the type of service in the packet sent. The default is zero. TOS is specified as a decimal value between 0 and 255.

-w timeout Specifies the time in milliseconds for packet timeout. If a reply is not received within the timeout, the Request Timed Out error message is displayed. The default timeout is four seconds.

TargetName Specifies the hostname or IP address of the destination to ping.

Note

Some remote hosts may be configured to ignore PING traffic as a method of preventing acknowledgment as a security measure. Therefore, your inability to ping a server may not necessarily mean that the server is not operational, just that the server is not responding for some reason.

Tracert

Tracert is generally used to determine the route or path taken to a destination by sending ICMP packets with varying Time to Live values. Each router the packet meets on the way decreases the value of the TTL by at least one; invariably, the TTL is a hop count. The path is determined by checking the ICMP Time Exceeded messages returned by intermediate routers. Some routers do not return Time Exceeded messages for expired TTL values and are not captured by Tracert. In such cases, asterisks are displayed for that hop.

To display the different parameters that can be used with Tracert, open a command prompt and type tracert (without parameters) to display help or type tracert /?. The parameters associated with Tracert are as follows:

-4 Specifies that tracert.exe can use only IPv4 for the trace.

-6 Specifies that tracert.exe can use only IPv6 for the trace.

-d Prevents resolution of IP addresses of routers to their hostname. This is particularly useful for speeding up results of Tracert.

-h maximumHops Specifies the maximum number of hops to take before reaching the destination. The default is 30 hops.

-j HostList Specifies that packets use the loose source route option. Loose source routing allows successive intermediate destinations to be separated by one or multiple routers. The maximum number of addresses in the host list is nine. This parameter is useful only when tracing IPv4 addresses.

-R Sends packets to a destination in IPv6, using the destination as an intermediate destination and testing reverse route.

-S Specifies the source address to use. This parameter is useful only when tracing IPv6 addresses.

Note

Tracert is a good utility to determine the number of hops and the latency of communications between two points. Even if an organization has an extremely high-speed connection to the Internet, if the Internet is congested or if the route a packet must follow requires forwarding the information between several routers along the way, the performance and ultimately the latency (or delay in response between servers) will cause noticeable communications delays.

Pathping

Pathping is a route tracing tool that combines both features of PING and TRacert commands with some more information that neither of those two commands provides. Pathping is most ideal for a network with routers or multiple routes between the source and destination hosts. The Pathping command sends packets to each router on its way to a destination, and then gets results from each packet returned from the router. Because Pathping computes the loss of packets from each hop, you can easily determine which router is causing a problem in the network.

To display the parameters in Pathping, open a command prompt and type Pathping /?. The parameters for the Pathping command are as follows:

-g Host-list Allows hosts to be separated by intermediate gateways.

-h maximumHops Specifies the maximum number of hops before reaching the target. The default is 30 hops.

-n Specifies that it is not necessary to resolve the address to the hostname.

-p period Specifies the number of seconds to wait between pings. The default is a quarter of a second.

-q Specifies the number of queries to each host along the route. The default is three seconds.

-R Determines whether the hosts along the route support Resource Reservation Setup Protocol. The route supports the Resource Reservation Setup Protocol to allow host computers to reserve bandwidth for data streams. Note that this parameter must be in uppercase.

-T Identifies network devices that do not have Layer 2 priority configured. This parameter must be in uppercase.

Ipconfig

Ipconfig displays all TCP/IP configuration values. It is of particular use on machines running DHCP. It is used to refresh DHCP settings and to determine which TCP/IP configuration values have been assigned by DHCP. If Ipconfig is used without parameters, it displays IP addresses, subnet masks, and gateways for adapters on a machine. The adapters can be physical network adapters or logical adapters such as dial-up connections.

The parameters for Ipconfig are as follows:

-all Displays all TCP/IP configuration values.

/displaydns Displays the contents of the DNS client resolver cache.

/flushdns Resets and flushes the contents of the DNS client resolver cache. This includes entries made dynamically.

/registerdns Sets manual dynamic registration for DNS names and IP addresses configured on a computer. This is particularly useful in troubleshooting DNS name registration or dynamic update problems between a DNS server and client.

/release [Adapter] Sends a DHCP release message to the DHCP server to discard DHCP-configured settings for adapters. This parameter is available only for DHCP-enabled clients. If no adapter is specified, IP address configuration is released for all adapters.

/renew [Adapter] Renews DHCP configuration for all adapters (if an adapter is not specified) and for a specific adapter if the Adapter parameter is included. This parameter is available only for DHCP-enabled clients.

/setclassid Adapter [classID] Configures the DHCP Class ID for a specific adapter. You can configure the DHCP class ID for all adapters by using the wildcard (*) character in place of Adapter.

/showclassid Adapter Displays the DHCP class ID for a specific adapter.

Note

Ipconfig determines the assigned configuration for a system such as the default gateway, DNS servers, local IP address, subnet mask, and the like. When you're debugging network problems, you can use Ipconfig to validate that the proper TCP/IP settings have been set up for a system so that a server properly communicates on the network.

Arp

Arp stands for Address Resolution Protocol. Arp enables the display and modification of the Arp table on a local machine, which matches physical MAC addresses of machines to their corresponding IP addresses. Arp increases the speed of connection by eliminating the need to match MAC addresses with IP addresses for subsequent connections.

The parameters for Arp are as follows:

-a [InetAddr] [-N IfaceAddr] Displays the Arp table for all adapters on a machine. Use Arp -a with the InetAddr (IP address) parameter to display the ARP cache entry for a specific IP address.

-d InetAddr [IfaceAddr] Deletes an entry with a specific IP address (InetAddr). Use the IfaceAddr parameter (IP address assigned to the interface) to delete an entry in a table for a specific interface. Use the wildcard character in place of InetAddr to delete all entries.

-g [InetAddr] [-N IfaceAddr] Similar to the a parameter.

-s InetAddr EtherAddr [IfaceAddr] Adds a static entry to the ARP cache that resolves the IP address (InetAddr) to a physical address (EtherAddr). To add a static ARP cache entry to the table for a specific interface, use the IP address assigned to the interface (IfaceAddr).

Netstat

As its name implies, Netstat (or Network Statistics) is used to display protocol statistics for any active connections, monitor connections to a remote host, and monitor IP addresses or domain names of hosts with established connections.

The parameters for Netstat are as follows:

-a Displays all connections and listening ports by hostname.

-an Similar to the a parameter, but displays connections and listening ports by IP addresses.

-e Displays Ethernet packets and bytes to and from the host.

-n Displays address and port numbers without resolving the address to the hostname.

-o Displays TCP connections and includes the corresponding process ID (PID). Used in combination with a, -n, and p. Not available in previous Windows versions.

-P protocol Displays statistics based on the protocol specified. Protocols that can be specified are TCP, UDP, TCPv6, or UDPv6. It can be used with s to display TCP, UDP, ICMP, IP, TCPv6, UDPv6, ICMPv6, or IPv6.

-s Displays statistics on a protocol-by-protocol basis. Can be used with the p parameter to specify a set of protocols.

-r Displays the route table. Information displayed includes network destination, netmask, gateway, interface, and metric (number of hops).

[Parameter] Interval Displays the information at every interval specified. Interval is a numeral in seconds. Press Ctrl+C to stop the intervals.

NetDiag

The Network Connectivity Tester (NetDiag) tool is a command-line diagnostic tool to test network connectivity, configuration, and security. It's included with the Support Tools on the Windows Server 2003 media. The tool gathers information on and tests network configuration, network drivers, protocols, connectivity, and well-known target accessibility. This is a good tool to use right off the bat if you think there are problems with the network connectivity of a system.

One nice feature of the NetDiag.exe tool is that it does not require parameters, which makes it easy to use. Simple instructions can be given to the administrators that need to execute it, and the bulk of the time can be spent analyzing the results.

Although it doesn't require any parameters, there are several available:

/q Quiet output (errors only).

/v Verbose output.

/l Logs to the NetDiag.log.

/debug Even more verbose output.

/d: DomainName Finds a domain controller in the domain.

/fix Fixes minor problems.

/DCAccountEnum Enumerates domain controller computer accounts.

/test: TestName Runs the specified tests only.

/skip: TestName Skips the specified tests.

When specifying tests to run or to skip, nonskippable tests will still be run.

DCDiag

The Domain Controller Diagnostic (DCDiag) tool analyzes the state of domain controllers and services in an Active Directory forest. It is included with the Support Tools on the Windows Server 2003 media. This is a great general-purpose test tool for checking the health of an Active Directory infrastructure.

Tests include domain controller connectivity, replication errors, permissions, proper roles and connectivity, and other general Active Directory health checks. It can even run nondomain controllerspecific tests, such as whether a server can be promoted to a domain controller (the DcPromo test), or register its records properly in DNS (RegisterInDNS test).

DCDiag is run on domain controllers exclusively, with the exception of the DcPromo and RegisterInDNS tests. When run without any parameters, the tests will be run against the current domain controller. This runs all the key tests and is usually sufficient for most purposes.

The parameters for DCDiag are as follows:

/s:DomainController Uses the domain controller as the home server.

/n:NamingContext Uses the specified naming context (NetBIOS, FQDN, or distinguished name) to test.

/u:Domain\UserName /p:{* Password ""} Uses the supplied credentials to run the tool.

/a Tests all domain controllers in the site.

/e Tests all domain controllers in the enterprise.

/q Quiet output (errors only).

/v Verbose output.

/I Ignores minor error messages.

/fix Fixes minor problems.

/f:LogFile Logs to the specified log file.

/ferr:ErrorLogFile Logs errors to the specified log file.

/c Comprehensively runs all tests.

/test:TestName Runs the specified tests only.

/skip:TestName Skips the specified tests.

When specifying tests to run or to skip, nonskippable tests will still be run.

Route

Route is particularly useful for troubleshooting incorrect static routes or for adding a route to a route table to temporarily bypass a problem gateway. Static routes can be used in place of implicit routes specified by a default gateway. Use Route to add static routes to forward packets going to a gateway specified by default to avoid loops, improve traffic time, and so on.

The parameters for Route are as follows:

-add Adds a route to a table. Use p to make the route persistent for subsequent sessions.

-Delete Deletes a route from the table.

-Print Prints a route.

-change Modifies an existing route.

-destination Specifies the host address.

-gateway Specifies the address of gateway for Route.

IF interface Specifies the interface for the routing table to modify.

-mask Netmask Uses the subnet mask specified by Netmask. If mask is not used, it defaults to 255.255.255.255.

-METRIC MeTRic Specifies the metric, or cost, for the route using the value Metric.

-f Clears the routing table of all gateway entries.

-p Used with -add to create a persistent route.

Nslookup

Nslookup is used to query DNS. You can think of Nslookup as a simple diagnostic client for DNS servers. It can operate in two modes: interactive and noninteractive. Use noninteractive mode to look up a single piece of data. To look up more than one piece of data, use interactive mode. To stop interactive mode at any time, press Ctrl+B. To exit from the command, type exit. If Nslookup is used without any parameters, it uses the default DNS name server for lookup.

The parameters for Nslookup are as follows:

-ComputerToFind Looks up information for the specified ComputerToFind. By default, it uses the current default DNS name server.

-Server Specifies the server as the DNS name server.

-SubCommand Specifies one or more Nslookup subcommands as a command-line option. Type a question mark (?) to display a list of subcommands available.

System Startup and Recovery

The System Startup and Recovery utility stores system startup, system failure, and debugging information. It also controls the behavior (what to do) when a system failure occurs.

To open System Startup and Recovery, right-click My Computer, select Properties, select the Advanced tab, and then click Settings under Startup and Recovery to display a property page similar to the one shown in Figure 34.15.

Figure 34.15. The Startup and Recovery page.

The Default Operating System field contains information that is displayed at startup. This information is typically the name of the operating system such as Microsoft Windows Server 2003 Enterprise server. You can edit this information by clicking the Edit button or by editing the boot.ini file. If the machine is dual-booted, there will be an entry for each operating system. The Time to Display List of Operating Systems option specifies the time the system takes to display the name of the operating system at startup. The default time is 30 seconds. This can be increased or reduced to a different time.

You can set the action to be taken when system failure occurs in the System Failure section. There are three options. The first option is Write an Event to the System Log. This action is not available on Windows Server 2003 because this action occurs by default every time a stop error occurs. The second option, Send an Administrative Alert, sends an alert. The last option, Automatically Restart, automatically reboots the system in the event of a system failure.

The Write Debugging Information section tells the system where to write debugging information when a system failure occurs. The options available include where the debugging information can be written to Small memory dump (64KB), Kernel memory dump, Complete memory dump, or (none). The Write Debugging Information To option requires a paging file on the boot volume, which should be the size of the physical RAM plus 1MB. Thus, a system with 512MB of RAM will create a paging file 513MB in size.

Memory resources can be saved if the Write Debugging Information To option is set to (none) and the Send an Administrative Alert option is unchecked. The memory that would be saved depends on the server; the drivers that enable these features require about 60 to 70KB.

Memory-Related Debugging

Many troubleshooting scenarios revolve around memory-related issues, such as an errant application or process consuming too much memory. The Windows Server 2003 Resource Kit provides many useful utilities that can assist in the troubleshooting process. However, there are two that are specifically designed for memory:

  • Memory Monitor (memmonitor.exe) This command-line tool monitors a process' memory and can debug the memory in use after a specific threshold has been reached.

  • Resource Leak Triage Tool (memtriage.exe) If a process takes up memory and never releases the memory back to the system, a memory leak occurs. Use this tool to monitor, log, and analyze memory usage and more easily determine whether a process is causing a memory leak.

The Software Error-Reporting Mechanism

Software errors can be reported in Windows Server 2003. The error-reporting mechanism makes this happen. The errors reported in the error-reporting mechanism can be sent to Microsoft to help improve its future products.

You can open this mechanism by right-clicking My Computer, selecting Properties, selecting the Advanced tab, and clicking the Error Reporting button to display a screen similar to the one in Figure 34.16. You can disable software error reporting by selecting the Disable Error Reporting radio button.

Figure 34.16. Error Reporting screen.

The other option is to allow software error reporting. You enable it by selecting Enable Error Reporting. Options are available to report all or one of the following: Windows Operating System, Unplanned Machine Shutdowns, Programs (you can select programs you want by clicking the Choose Programs button), and Force Queue Mode for Program Errors.

Dr. Watson for Windows

Dr. Watson for Windows is a program debugger. The Microsoft technical support team can use the information obtained and logged by Dr. Watson for troubleshooting purposes. A text file is generated whenever an error occurs. A crash dump file can also be generated when an error occurs.

Dr. Watson starts automatically when a program error occurs. However, you can also start it from a command prompt by typing drwtsn32. After Dr. Watson is started, a screen similar to the one in Figure 34.17 is shown.

Figure 34.17. Dr. Watson for Windows screen.

The log file generated by Dr. Watson can be viewed in a text editor. This file contains information such as process ID of the application, date and time of occurrence, error that occurred, program that caused the error, function name, task identifier, and so on.


Summary

Logging and debugging tools help administrators monitor, manage, and problem-solve errors on the network. Many of the tools used to identify network problems in a Windows Server 2003 environment have been improved from previous versions of the applications in earlier releases of the Windows operating system. Key to problem solving is enabling logging and monitoring the logs to identify errors, research the errors, and perform system recovery based on problem resolution.

In addition to the tools and utilities that come with the Windows Server 2003 environment are resources such as the Microsoft TechNet database (http://www.microsoft.com/technet/). Between utility and tool improvements as well as online technical research databases, problem solving can be simplified in a Windows Server 2003 networking environment.


Best Practices

  • Use the Task Manager to provide an instant view of system resources, such as processor activity, process activity, memory usage, and resource consumption.

  • Use the Event Viewer to check whether Windows Server 2003 is experiencing problems.

  • Filter for specific events in the Event Viewer.

  • Archive security logs to a central location on your network and then review them periodically against local security logs.

  • Set an auditing policy to shut down the server immediately when the security log is full. This will prevent generated logs from being overwritten or old logs from being erased.

  • Establish a process for monitoring and analyzing system performance to promote maximum uptime and to meet service-level agreements.

  • Run the System Monitor from a remote computer to monitor servers.

  • Use logging when monitoring a larger number of servers.

  • Establish performance baselines.

  • Create new baselines as applications or new services are added to a server.

  • Consider reducing the frequency of data collection to reduce the amount of data that must be collected and analyzed.

  • Use logs to capture performance data.

  • Filter data captured from Netmon to assist with administration, maintenance, and troubleshooting efforts.

  • Consult the Windows Server 2003 Resource Kit for tools and documentation to assist with monitoring, analyzing, and troubleshooting.

  • Don't use the INCLUDE and EXCLUDE filters in Netmon at the same time.

  • Use Tracert to determine the number of hops and the latency of communications between two points.


Chapter 35. Capacity Analysis and Performance Optimization

In This Chapter

  • Defining Capacity Analysis

  • Establishing Policy and Metric Baselines

  • Using Capacity-Analysis Tools

  • Monitoring System Performance

  • Optimizing Performance by Server Roles

  • Using Server Performance Analyzer 2.0

  • Managing Patches

Capacity analysis and performance optimization are two intertwined processes that are too often neglected; however, these processes address common questions when you are faced with designing or supporting a network environment. The reasons for the neglect are endless, but most often IT professionals are simply tied up with daily administration and firefighting, or the perception of mystery surrounding these procedures is intimidating. These processes require experience and insight. Equally important is the fact that handling these processes is an art, but it doesn't require a crystal ball. If you invest time in these processes, you will spend less time troubleshooting or putting out fires, thus making your life less stressful and also reducing business costs.


Defining Capacity Analysis

The majority of capacity analysis is working to minimize unknown or immeasurable variables, such as the number of gigabytes or terabytes of storage the system will need in the next few months or years, to adequately size a system. The high number of unknown variables is largely because network environments, business policy, and people are constantly changing. As a result, capacity analysis is an art as much as it involves experience and insight.

If you've ever found yourself having to specify configuration requirements for a new server or having to estimate whether your configuration will have enough power to sustain various workloads now and in the foreseeable future, proper capacity analysis can help in the design and configuration. These capacity-analysis processes help weed out the unknowns and assist you while making decisions as accurately as possible. They do so by giving you a greater understanding of your Windows Server 2003 environment. This knowledge and understanding can then be used to reduce time and costs associated with supporting and designing an infrastructure. The result is that you gain more control over the environment, reduce maintenance and support costs, minimize firefighting, and make more efficient use of your time.

Business depends on network systems for a variety of different operations, such as performing transactions or providing security, so that the business functions as efficiently as possible. Systems that are underutilized are probably wasting money and are of little value. On the other hand, systems that are overworked or can't handle workloads prevent the business from completing tasks or transactions in a timely manner, may cause a loss of opportunity, or may keep the users from being productive. Either way, these systems are typically not much benefit to operating a business. To keep network systems well tuned for the given workloads, capacity analysis seeks a balance between the resources available and the workload required of the resources. The balance provides just the right amount of computing power for given and anticipated workloads.

This concept of balancing resources extends beyond the technical details of server configuration to include issues such as gauging the number of administrators that may be needed to maintain various systems in your environment. Many of these questions relate to capacity analysis, and the answers aren't readily known because they can't be predicted with complete accuracy.

To lessen the burden and dispel some of the mysteries of estimating resource requirements, capacity analysis provides the processes to guide you. These processes include vendor guidelines, industry benchmarks, analysis of present system resource utilization, and more. Through these processes, you'll gain as much understanding as possible of the network environment and step away from the compartmentalized or limited understanding of the systems. In turn, you'll also gain more control over the systems and increase your chances of successfully maintaining the reliability, serviceability, and availability of your system.

There is no set or formal way to start your capacity-analysis processes. However, a proven and effective means to begin to proactively manage your system is to first establish system-wide policies and procedures. Policies and procedures, discussed shortly, help shape service levels and users' expectations. After these policies and procedures are classified and defined, you can more easily start characterizing system workloads, which will help gauge acceptable baseline performance values.

The Benefits of Capacity Analysis

The benefits of capacity analysis are almost inconceivable. Capacity analysis helps define and gauge overall system health by establishing baseline performance values, and then the analysis provides valuable insight into where the system is heading. It can be used to uncover both current and potential bottlenecks and can also reveal how changing management activities may affect performance today and tomorrow. It also allows you to identify and resolve performance issues proactively instead of before they become an issue or are recognized by management.

Another benefit of capacity analysis is that it can be applied to small environments and scale well into enterprise-level systems. The level of effort needed to initially drive the capacity-analysis processes will vary depending on the size of your environment, geography, and political divisions. With a little upfront effort, you'll save time, expense, and gain a wealth of knowledge and control over the network environment.


Establishing Policy and Metric Baselines

As mentioned earlier, it is recommended that you first begin defining policies and procedures regarding service levels and objectives. Because each environment varies in design, the policies that you create can't be cookie-cutter; you need to tailor them to your particular business practices and to the environment. In addition, you should strive to set policies that set user expectations and, more importantly, help winnow out empirical data.

Essentially, policies and procedures define how the system is supposed to be usedestablishing guidelines to help users understand that the system can't be used in any way they see fit. Many benefits are derived from these policies and procedures. For example, in an environment where policies and procedures are working successfully and where network performance becomes sluggish, it would be safer to assume that groups of people weren't playing a multiuser network game, that several individuals weren't sending enormous email attachments to everyone in the global address list, or that a rogue Web or FTP server wasn't placed on the network.

The network environment is shaped by the business more so than the IT department. Therefore, it's equally important to gain an understanding of users' expectations and requirements through interviews, questionnaires, surveys, and more. Some examples of policies and procedures that you can implement in your environment pertaining to end users could be the following:

  • Message size can't exceed 2MB.

  • Beta software can be installed only on lab equipment (that is, not on client machines or servers in the production environment).

  • All computing resources are for business use only (in other words, no gaming or personal use of computers is allowed).

  • Only certain applications will be supported and allowed on the network.

  • All home directories will be limited to 300MB per user.

  • Users must either fill out the technical support Outlook form or request assistance through the advertised help desk phone number.

Policies and procedures, however, aren't just for your end users. They can also be established and applied to IT personnel. In this scenario, policies and procedures can serve as guidelines for technical issues, rules of engagement, or simply an internal set of rules to abide by. The following list provides some examples of policies and procedures that might be applied to the IT personnel:

  • System backups must include system state data and should be completed by 5:00 a.m. each workday.

  • Routine system maintenance should be performed only on Saturday mornings between 5:00 and 8:00 a.m.

  • Basic technical support requests should be attended to within two business days.

  • Priority technical support requests should be attended to within four hours of the request.

  • Technical support staff should use Remote Desktop on client machines first before attempting to solve the problem locally.

  • Any planned downtime for servers must be approved by the IT Director at least one week in advance.

Benchmark Baselines

If you've begun defining policies and procedures, you're already cutting down the number of immeasurable variables and amount of empirical data that challenge your decision-making process. The next step to prepare for capacity analysis is to begin gathering baseline performance values.

Baselines give you a starting point in which to compare results against. For the most part, determining baseline performance levels involves working with hard numbers that represent the health of a system. On the other hand, a few variables coincide with the statistical representations such as workload characterization, vendor requirements or recommendations, industry-recognized benchmarks, and the data that you collect.

Workload Characterization

It is unlikely that each system in your environment is a separate entity that has its own workload characterization. Most, if not all, network environments have systems that depend on other systems or are even intertwined among different workloads. This makes workload characterization difficult at best.

Workloads are defined by how processes or tasks are grouped, the resources they require, and the type of work being performed. Examples of how workloads can be characterized include departmental functions, time of day, the type of processing required (such as batch or real-time), companywide functions (such as payroll), volume of work, and much more.

So, why is workload characterization so important? Identifying systems' workloads allows you to determine the appropriate resource requirements for each of them. This way, you can properly plan the resources according to the performance levels the workloads expect and demand.

Benchmarks

Benchmarks are a means to measure the performance of a variety of products, including operating systems, virtually all computer components, and even entire systems. Many companies rely on benchmarks to gain competitive advantage because so many professionals rely on them to help determine what's appropriate for their network environment.

As you would suspect, sales and marketing departments all too often exploit the benchmark results to sway IT professionals over their way. For this reason, it's important to investigate the benchmark results and the companies or organizations that produced the results. Vendors, for the most part, are honest with the results, but it's always a good idea to check with other sources, especially if the results are suspicious. For example, if a vendor has supplied benchmarks for a particular product, check to make sure that the benchmarks are consistent with other benchmarks produced by third-party organizations (such as magazines, benchmark organizations, and in-house testing labs). If none are available, you should try to gain insight from other IT professionals or run benchmarks on the product yourself before implementing it in production.

Although some suspicion may arise from benchmarks because of the sales and marketing techniques, the real purpose of benchmarks is to point out the performance levels that you can expect when using the product. Benchmarks can be extremely beneficial for decision-making, but they shouldn't be your sole source for evaluating and measuring performance. Use the benchmark results only as a guideline or starting point when consulting benchmark results during capacity analysis. It's also recommended that you pay close attention to their interpretation.

Table 35.1 lists companies or organizations that provide benchmark statistics and benchmark-related information, and some also offer tools for evaluating product performance.

Table 35.1. Organizations That Provide Benchmarks

Company/Organization Name

Web Address

Transaction Processing Council

http://www.tpc.org/

VeriTest

http://www.etestinglabs.com/

Computer Measurement Group

http://www.cmg.org/


Using Capacity-Analysis Tools

A growing number of tools originating and evolving from the Windows NT4, Windows 2000, and Unix operating system platforms can be used in data collection and analysis on Windows Server 2003. Some of these tools are even capable of forecasting system capacity, depending on the amount of information they are given.

In the past year Microsoft has released several sizing tools. Probably the most well known is the Microsoft Operations Manager (MOM) sizing tool; however, similar tools are available for any number of Microsoft applications. They are presented in the form of an interactive Microsoft Excel spreadsheet. The user inputs data relative to their environment, and the tool returns the recommended hardware configuration to support the request. They are based on Microsoft best practices and have been fairly accurate in practical use.

Microsoft also offers some handy utilities that are either inherent to Windows Server 2003 or are sold as separate products. Some of these utilities are included with the operating system, such as Task Manager, Network Monitor, and Performance Console (also known as Performance or System Monitor). Data that is collected from these applications can be exported to other applications, such as Microsoft Excel or Access, for inventory and analysis. Other Microsoft utilities that are sold separately are Systems Management Server (SMS) and MOM.

Built-in Toolset

Windows Server 2003's arsenal of utilities for capacity-analysis purposes includes command-line and GUI-based tools. This section discusses the Task Manager, Network Monitor, and Performance Console, which are bundled with the Windows Server 2003 operating system.

Task Manager

The Windows Server 2003 Task Manager is similar to its Windows 2000 predecessor in that it offers multifaceted functionality. You can view and monitor processor-, memory-, application-, network-, and process-related information in real-time for a given system. This utility is great for getting a quick view of key system health indicators with the lowest performance overhead.

To begin using Task Manager, use any of the following methods:

  • Press Ctrl+Shift+Esc.

  • Right-click the taskbar and select Task Manager.

  • Press Ctrl+Alt+Delete and then click Task Manager.

When you start the Task Manager, you'll see a screen similar to that in Figure 35.1.

Figure 35.1. The Task Manager window after initialization.

The Task Manager window contains the following five tabs:

  • Applications This tab lists the user applications that are currently running. You also can start and end applications under this tab.

  • Processes Under this tab, you can find performance metric information of the processes currently running on the system.

  • Performance This tab can be a graphical or tabular representation of key system parameters in real-time.

  • Networking This tab displays the network traffic coming to and from the machine. The displayed network usage metric is a percentage of total available network capacity for a particular adapter.

  • Users This tab displays users who are currently logged on to the system.

In addition to the Task Manager tabs, the Task Manager is, by default, configured with a status bar at the bottom of the window. This status bar, shown in Figure 35.2, displays the number of running processes, CPU utilization percentage, and the amount of memory currently being used.

Figure 35.2. All processes currently running on the system.

As you can see, the Task Manager presents a variety of valuable real-time performance information. This tool is particularly useful for determining what processes or applications are problematic and gives you an overall picture of system health.

There are limitations, however, which prevent it from becoming a useful tool for long-term or historical analysis. For example, the Task Manager can't store collected performance information; it is capable of monitoring only certain aspects of the system's health, and the information that is displayed pertains only to the local machine. For these reasons alone, the Task Manager doesn't make a prime candidate for capacity-planning purposes (you must be logged on locally or connected via Terminal Services to gauge performance with the Task Manager).

Network Monitor

There are two versions of Network Monitor that you can use to check network performance. The first is bundled within Windows Server 2003, and the other is a part of Systems Management Server. Although both have the same interface, like the one shown in Figure 35.3, the one bundled with the operating system is slightly scaled down in terms of functionality when compared to the SMS version.

Figure 35.3. The unified interface of the Network Monitor.

[View full size image]

The Network Monitor that is built into Windows Server 2003 is designed to monitor only the local machine's network activity. This utility design stems from security concerns regarding the ability to capture and monitor traffic on remote machines. If the operating system version had this capability, anyone who installed the Network Monitor would possibly be able to use it to gain unauthorized access to the system. Therefore, this version captures only frame types traveling into or away from the local machine.

To install the Network Monitor, perform the following steps:

1. | Select Add or Remove Programs from the Start, Control Panel menu.
2. | In the Add or Remove Programs window, click Add/Remove Windows Components.
3. | Within the Windows Components Wizard, select Management and Monitoring Tools and then click Details.
4. | In the Management and Monitoring Tools window, select Network Monitor Tools and then click OK.
5. | If you are prompted for additional files, insert your Windows Server 2003 CD or type a path to the location of the files on the network.
6. | After the installation, locate and execute the Network Monitor from the Start, Programs, Administration Tools menu.

As mentioned earlier, the SMS version of the Network Monitor is a full version of the one integrated into Windows Server 2003. The most significant difference between the two versions is that the SMS version can run indiscriminately throughout the network (that is, it can monitor and capture network traffic to and from remote machines). It is also equipped to locate routers on the network, provide name-to-IP address resolution, and generally monitor all the traffic traveling throughout the network.

Because the SMS version of Network Monitor is capable of capturing and monitoring all network traffic, it poses possible security risks. Any unencrypted network traffic can be compromised; therefore, it's imperative that you limit the number of IT personnel who have the necessary access to use this utility.

On the other hand, the SMS version of Network Monitor is more suitable for capacity-analysis purposes because it is flexible enough to monitor network traffic from a centralized location. It also allows you to monitor in real-time and capture for historical analysis. For all practical purposes, however, it wouldn't make much sense to install SMS just for the Network Monitor capabilities, especially considering that you can purchase more robust third-party utilities.

The Performance Console

Many IT professionals rely on the Performance Console because it is bundled with the operating system, and it allows you to capture and monitor every measurable system object within Windows Server 2003. This tool is a Microsoft Management Console (MMC) snap-in, so using the tool involves little effort to become familiar with it. You can find and start the Performance Console from within the Administrative Tools group on the Start menu.

The Performance Console, shown in Figure 35.4, is by far the best utility provided in the operating system for capacity-analysis purposes. With this utility, you can analyze data from virtually all aspects of the system both in real-time and historically. This data analysis can be viewed through charts, reports, and logs. The log format can be stored for use later so that you can scrutinize data from succinct periods of time.

Figure 35.4. The Performance Console startup screen.

[View full size image]

Because the Performance Console is available to everyone running the operating system and it has a lot of built-in functionality, we'll assume that you'll be using this utility.

Third-Party Toolset

Without a doubt, many third-party utilities are excellent for capacity-analysis purposes. Most of them provide additional functionality not found in Windows Server 2003's Performance Console, but they cost more, too. You may want to evaluate some third-party utilities to get a more thorough understanding of how they may offer more features than the Performance Console. Generally speaking, these utilities enhance the functionality that's inherent to Performance Console, such as scheduling, an enhanced level of reporting functionality, superior storage capabilities, the ability to monitor non-Windows systems, or algorithms for future trend analysis. Some of these third-party tools are listed in Table 35.2.

Table 35.2. Third-Party Capacity-Planning Tools

Utility Name

Company

Web Site

AppManager Suite

NetIQ Corporation

http://www.netiq.com/solutions/systems/

Openview

Hewlett-Packard

http://www.openview.hp.com/

PATROL

BMC Software

http://www.bmc.com/

PerfMan

Information Systems

http://www.infosysman.com/

RoboMon

Heroix

http://www.robomon.com/

Unicenter TNG

Computer Associates

http://www.ca.com/

Although it may be true that most third-party products do add more functionality to your capacity-analysis procedures, there are still pros and cons to using them over the free Performance Console. The most obvious is the expense of purchasing the software licenses for monitoring the enterprise, but some less obvious factors include the following:

  • The number of administrators needed to support the product in capacity-analysis procedures is higher.

  • Some third-party products have higher learning curves associated with them. This increases the need for either vendor or in-house training just to support the product.

The key is to decide what you need to adequately and efficiently perform capacity-analysis procedures in your environment. You may find that the Performance Console is more than adequate, or you may find that your network environment, because of complexities, requires a third-party product that can encompass all the intricacies.


Monitoring System Performance

Capacity analysis is not about how much information you can collect; it is, however, about collecting the appropriate system health indicators and the right amount of information. Without a doubt, you can capture and monitor an overwhelming amount of information from performance counters. There are more than 1,000 counters, so you'll want to carefully choose what to monitor. Otherwise, you may collect so much information that the data will be hard to manage and difficult to decipher. Keep in mind that more is not necessarily better with regard to capacity analysis. This process is more about efficiency. Therefore, you need to tailor your capacity-analysis monitoring as accurately as possible to how the server is configured.

Every Windows Server 2003 has a common set of resources that can affect performance, reliability, stability, and availability. For this reason, it's important that you monitor this common set of resources.

Four resources comprise the common set of resources: memory, processor, disk subsystem, and network subsystem. They are also the most common contributors to performance bottlenecks. A bottleneck can be defined in two ways. The most common perception of a bottleneck is that it is the slowest part of your system. It can either be hardware or software, but generally speaking, hardware is usually faster than software. When a resource is overburdened or just not equipped to handle higher workload capacities, the system may experience a slowdown in performance. For any system, the slowest component of the system is, by definition, considered the bottleneck. For example, a Web server may be equipped with ample RAM, disk space, and a high-speed network interface card (NIC), but if the disk subsystem has older drives that are relatively slow, the Web server may not be able to effectively handle requests. The bottleneck (that is, the antiquated disk subsystem) can drag the other resources down.

A less common, but equally important form of bottleneck, is one where a system has significantly more RAM, processors, or other system resources than the application requires. In these cases, the system creates extremely large pagefiles, has to manage very large sets of disk or memory sets, yet never uses the resources. When an application needs to access memory, processors, or disks, the system may be busy managing the idle resource, thus creating an unnecessary bottleneck caused by having too many resources allocated to a system. Thus, performance optimization not only means having too few resources, but also means not having too many resources allocated to a system.

In addition to the common set of resources, the functions that the Windows Server 2003 performs can influence what you should consider monitoring. So, for example, you would monitor certain aspects of system performance on file servers differently than you would for a domain controller (DC). There are many functional roles (such as file and print sharing, application sharing, database functions, Web server duties, domain controller roles, and more) that Windows Server 2003 can serve under, and it is important to understand all those roles that pertain to each server system. By identifying these functions and monitoring them along with the common set of resources, you gain much greater control and understanding of the system.

The following sections go more in depth on what specific counters you should monitor for the different components that comprise the common set of resources. It's important to realize though that there are several other counters that you should consider monitoring in addition to the ones described in this chapter. You should consider the following material a baseline of the minimum number of counters to begin your capacity-analysis and performance-optimization procedures.

Later in the chapter, we will identify several server roles and cover monitoring baselines, describing the minimum number of counters to monitor.

Key Elements to Monitor

The key elements to begin your capacity analysis and performance optimization are the common contributors to bottlenecks. They are memory, processor, disk subsystem, and network subsystem.

Monitoring System Memory

Available system memory is usually the most common source for performance problems on a system. The reason is simply that incorrect amounts of memory are usually installed on a Windows Server 2003 system. By definition, Windows Server 2003 tends to consume a lot of memory. Fortunately, the easiest and most economical way to resolve the performance issue is to configure the system with additional memory. This can significantly boost performance and upgrade reliability.

When you first start the Performance Console in Windows Server 2003, three counters are monitored. One of these counters is an important one related to memory: the Pages/sec counter. The Performance Console's default setting is illustrated in Figure 35.4. It shows three counters being monitored in real-time. The purpose is to provide a simple and quick way to get a basic idea of system health.

There are many significant counters in the memory object that could help determine system memory requirements. Most network environments shouldn't need to consistently monitor every single counter to get accurate representation of performance. For long-term monitoring, two very important counters can give you a fairly accurate picture of memory requirements: Page Faults/sec and Pages/sec memory. These two memory counters alone can indicate whether the system is properly configured with the proper amount of memory.

Systems experience page faults when a process requires code or data that it can't find in its working set. A working set is the amount of memory that is committed to a particular process. In this case, the process has to retrieve the code or data in another part of physical memory (referred to as a soft fault) or, in the worst case, has to retrieve it from the disk subsystem (a hard fault). Systems today can handle a large number of soft faults without significant performance hits. However, because hard faults require disk subsystem access, they can cause the process to wait significantly, which can drag performance to a crawl. The difference between memory and disk subsystem access speeds is exponential even with the fastest drives available.

The Page Faults/sec counter reports both soft and hard faults. It's not uncommon to see this counter displaying rather large numbers. Depending on the workload placed on the system, this counter can display several hundred faults per second. When it gets beyond several hundred page faults per second for long durations, you should begin checking other memory counters to identify whether a bottleneck exists.

Probably the most important memory counter is Pages/sec. It reveals the number of pages read from or written to disk and is therefore a direct representation of the number of hard page faults the system is experiencing. Microsoft recommends upgrading the amount of memory in systems that are seeing Pages/sec values consistently averaging above 5 pages per second. In actuality, you'll begin noticing slower performance when this value is consistently higher than 20. So, it's important to carefully watch this counter as it nudges higher than 10 pages per second.

Note

The Pages/sec counter is also particularly useful in determining whether a system is thrashing. Thrashing is a term used to describe systems experiencing more than 100 pages per second. Thrashing should never be allowed to occur on Windows Server 2003 systems because the reliance on the disk subsystem to resolve memory faults greatly affects how efficiently the system can sustain workloads.

Analyzing Processor Usage

Most often the processor resource is the first one analyzed when there is a noticeable decrease in system performance. For capacity-analysis purposes, you should monitor two counters: % Processor Time and Interrupts/sec.

The % Processor Time counter indicates the percentage of overall processor utilization. If more than one processor exists on the system, an instance for each one is included along with a total (combined) value counter. If this counter averages a usage rate of 50% or greater for long durations, you should first consult other system counters to identify any processes that may be improperly using the processors or consider upgrading the processor or processors. Generally speaking, consistent utilization in the 50% range doesn't necessarily adversely affect how the system handles given workloads. When the average processor utilization spills over the 65 or higher range, performance may become intolerable.

The Interrupts/sec counter is also a good guide of processor health. It indicates the number of device interrupts that the processor (either hardware or software driven) is handling per second. Like the Page Faults/sec counter mentioned in the "Memory" section, this counter may display very high numbers (in the thousands) without significantly impacting how the system handles workloads.

Evaluating the Disk Subsystem

Hard disk drives and hard disk controllers are the two main components of the disk subsystem. Windows Server 2003 only has Performance Console objects and counters that monitor hard disk statistics. Some manufacturers, however, may provide add-in counters to monitor their hard disk controllers. The two objects that gauge hard disk performance are Physical and Logical Disk. Unlike its predecessor (Windows 2000), Windows Server 2003 automatically enables the disk objects by default when the system starts.

Although the disk subsystem components are becoming more and more powerful, they are often a common bottleneck because their speeds are exponentially slower than other resources. The effects, though, may be minimal and maybe even unnoticeable, depending on the system configuration.

Monitoring with the Physical and Logical Disk objects does come with a small price. Each object requires a little resource overhead when you use them for monitoring. As a result, you should keep them disabled unless you are going to use them for monitoring purposes. To deactivate the disk objects, type diskperf -n. To activate them at a later time, use diskperf -y or diskperf -y \\mycomputer to enable them on remote machines that aren't running Windows Server 2003. Windows Server 2003 is also very flexible when it comes to activating or deactivating each object separately. To specify which object to enable or disable, use a d for the Physical Disk object, or a v for the Logical Disk object.

Activating and deactivating the disk subsystem objects in Windows Server 2003 is fairly straightforward. Use diskperf -y to activate all disk counters, diskperf -y \\mycomputer to enable them on remote machines, or diskperf -n to deactivate them. Windows Server 2003 is also very flexible when it comes to activating or deactivating each object separately. To specify which object to enable or disable, use a d for the Physical Disk object or a v for the Logical Disk object.

To minimize system overhead, disable the disk performance counters if you don't plan on monitoring them in the near future. For capacity-analysis purposes, though, it's important to always watch the system and keep informed of changes in usage patterns. The only way to do this is to keep these counters enabled.

So, what specific disk subsystem counters should be monitored? The most informative counters for the disk subsystem are % Disk Time and Avg. Disk Queue Length. The % Disk Time counter monitors the time that the selected physical or logical drive spends servicing read and write requests. The Avg. Disk Queue Length monitors the number of requests not yet serviced on the physical or logical drive. The Avg. Disk Queue length value is an interval average; it is a mathematical representation of the number of delays the drive is experiencing. If the delay is frequently greater than 2, the disks are not equipped to service the workload and delays in performance may occur.

Monitoring the Network Subsystem

The network subsystem is by far one of the most difficult subsystems to monitor because of the many different variables. The number of protocols used in the network, the network interface cards, network-based applications, topologies, subnetting, and more play vital roles in the network, but they also add to its complexity when you're trying to determine bottlenecks. Each network environment has different variables; therefore, the counters that you'll want to monitor will vary.

The information that you'll want to gain from monitoring the network pertains to network activity and throughput. You can find this information with the Performance Console alone, but it will be difficult at best. Instead, it's important to use other tools, such as the Network Monitor, in conjunction with Performance Console to get the best representation of network performance as possible. You may also consider using third-party network analysis tools such as sniffers to ease monitoring and analysis efforts. Using these tools simultaneously can broaden the scope of monitoring and more accurately depict what is happening on the wire.

Because the TCP/IP suite is the underlying set of protocols for a Windows Server 2003 network subsystem, this discussion of capacity analysis focuses on this protocol. The TCP/IP counters are added after the protocol is installed (by default).

There are several different network performance objects relating to the TCP/IP protocol, including ICMP, IPv4, IPv6, Network Interface, TCPv4, UDPv6, and more. Other counters such as FTP Server and WINS Server are added after these services are installed. Because entire books are dedicated to optimizing TCP/IP, this section focuses on a few important counters that you should monitor for capacity-analysis purposes.

First, examining error counters, such as Network Interface: Packets Received Errors or Packets Outbound Errors, is extremely useful in determining whether traffic is easily traversing the network. The greater the number of errors indicates that packets must be present, causing more network traffic. If a high number of errors is persistent on the network, throughput will suffer. This may be caused by a bad NIC, unreliable links, and so on.

If network throughput appears to be slowing because of excessive traffic, you should keep a close watch on the traffic being generated from network-based services such as the ones described in Table 35.3.

Table 35.3. Network-Based Service Counters to Monitor Network Traffic

Counter

Description

NBT Connection: Bytes Total/sec

Monitors the network traffic generated by NBT connections

Redirector: Bytes Total/sec

Processes data bytes received for statistical calculations

Server: Bytes Total/sec

Monitors the network traffic generated by the Server service


Optimizing Performance by Server Roles

In addition to monitoring the common set of bottlenecks (memory, processor, disk subsystem, and network subsystem), the functional roles of the server influence what other counters you should monitor. The following sections outline some of the most common roles for Windows Server 2003 that also require the use of additional performance counters.

Terminal Services Server

Terminal Server has its own performance objects for the Performance Console called the Terminal Services Session and Terminal Services objects. It provides resource statistics such as errors, cache activity, network traffic from Terminal Server, and other session-specific activity. Many of these counters are similar to those found in the Process object. Some examples include % Privileged Time, % Processor Time, % User Time, Working Set, Working Set Peak, and so on.

Note

You can find more information on Terminal Services in Chapter 27, "Windows Server 2003 Terminal Services."

Three important areas to always monitor for Terminal Server capacity analysis are the memory, processor, and application processes for each session. Application processes are by far the hardest to monitor and control because of the extreme variances in programmatic behavior. For example, all applications may be 32-bit, but some may not be certified to run on Windows Server 2003. You may also have in-house applications running on Terminal Services that may be poorly designed or too resource intensive for the workloads they are performing.

Domain Controllers

A Windows Server 2003 domain controller (DC) houses the Active Directory (AD) and may have additional roles such as being responsible for one or more Flexible Single Master Operation (FSMO) roles (schema master, domain naming master, relative ID master, PDC Emulator, or infrastructure master) or a global catalog (GC) server. Also, depending on the size and design of the system, a DC may serve many other functional roles. In this section, AD, replication, and DNS monitoring will be explored.

Monitoring AD

Active Directory is the heart of Windows Server 2003 systems. It's used for many different facets, including, but not limited to, authentication, authorization, encryption, and Group Policies. Because AD plays a central role in a Windows Server 2003 network environment, it must perform its responsibilities as efficiently as possible. You can find more information on Windows Server 2003's AD in Chapter 4, "Active Directory Primer." Each facet by itself can be optimized, but this section focuses on the NTDS and Database objects.

The NTDS object provides various AD performance indicators and statistics that are useful for determining AD's workload capacity. Many of these counters can be used to determine current workloads and how these workloads may affect other system resources. There are relatively few counters in this object, so it's recommended that you monitor each one in addition to the common set of bottleneck objects. With this combination of counters, you can determine whether the system is overloaded.

Another performance object that you should use to monitor AD is the Database object. This object is not installed by default, so you must manually add it to be able to start gathering more information on AD.

To load the Database object, perform the following steps:

1. | Copy the performance DLL (esentprf.dll) located in %SystemRoot%\System32 to any directory (for example, c:\esent).
2. | Launch the Registry Editor (Regedt32.exe).
3. | Create the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ _Services\ESENT.
4. | Create the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ _Services\ESENT\Performance.
5. | Select the ESENT\Performance subkey.
6. | Create the value Open using data type REG_SZ and string equal to OpenPerformanceData.
7. | Create the value Collect using the data type REG_SZ and string equal to CollectPerformanceData.
8. | Create the value Close using the data type REG_SZ and string equal to ClosePerformanceData.
9. | Create the value Library using the data type REG_SZ and string equal to c:\esent\esentprf.dll.
10. | Exit the Registry Editor.
11. | Open a command prompt and change the directory to %SystemRoot%\System32.
12. | Run Lodctr.exe Esentprf.ini at the command prompt.

After you complete the Database object installation, you can execute the Performance Console and use the Database object to monitor AD. Some of the relevant counters contained within the Database object to monitor AD are described in Table 35.4.

Table 35.4. AD Performance Counters

Counter

Description

Database Cache % Hit

The percentage of page requests for the database file that were fulfilled by the database cache without causing a file operation. If this percentage is low (85% or lower), you may consider adding more memory.

Database Cache Page Fault Stalls/sec

The number of page faults per second that cannot be serviced because there are no pages available for allocation from the database cache. This number should be low if the system is configured with the proper amount of memory.

Database Cache Page Faults/sec

The number of page requests per second for the database file that require the database cache manager to allocate a new page from the database cache.

Database Cache Size

The amount of system memory used by the database cache manager to hold commonly used information from the database to prevent file operations.

Monitoring DNS

The domain name system (DNS) has been the primary name resolution mechanism in Windows 2000 and continues to be with Windows Server 2003. For more information on DNS, refer to Chapter 9, "The Domain Name System." There are numerous counters available for monitoring various aspects of DNS in Windows Server 2003. The most important categories in terms of capacity analysis are name resolution response times and workloads as well as replication performance.

The counters listed in Table 35.5 are used to compute name query traffic and the workload that the DNS server is servicing. These counters should be monitored along with the common set of bottlenecks to determine the system's health under various workload conditions. If users are noticing slower responses, you can compare the query workload usage growth with your performance information from memory, processor, disk subsystem, and network subsystem counters.

Table 35.5. Counters to Monitor DNS

Counter

Description

Dynamic Update Received/sec

Dynamic Update Received/sec is the average number of dynamic update requests received by the DNS server in each second.

Recursive Queries/sec

Recursive Queries/sec is the average number of recursive queries received by the DNS server in each second.

Recursive Query Failure/sec

Recursive Query Failure/sec is the average number of recursive query failures in each second.

Secure Update Received/sec

Secure Update Received/sec is the average number of secure update requests received by the DNS server in each second.

TCP Query Received/sec

TCP Query Received/sec is the average number of TCP queries received by the DNS server in each second.

TCP Response Sent/sec

TCP Response Sent/sec is the average number of TCP responses sent by the DNS server in each second.

Total Query Received/sec

Total Query Received/sec is the average number of queries received by the DNS server in each second.

Total Response Sent/sec

Total Response Sent/sec is the average number of responses sent by the DNS server in each second.

UDP Query Received/sec

UDP Query Received/sec is the average number of UDP queries received by the DNS server in each second.

UDP Response Sent/sec

UDP Response Sent/sec is the average number of UDP responses sent by the DNS server in each second.

Comparing results with other DNS servers in the environment can also help you to determine whether you should relinquish some of the name query responsibility to other DNS servers that are less busy.

Replication performance is another important aspect of DNS. Windows Server 2003 supports legacy DNS replication, also known as zone transfers, which populate information from the primary DNS to any secondary servers. There are two types of legacy DNS replication: incremental (propagating only changes to save bandwidth) and full (the entire zone file is replicated to secondary servers).

Full zone transfers (AXFR) occur on the initial transfers and then the incremental zone transfers (IXFR) are performed thereafter. The performance counters for both AXFR and IXFR (see Table 35.6) measure both requests and the successful transfers. It is important to note that if your network environment integrates DNS with non-Windows systems, it is recommended to have those systems support IXFR.

Table 35.6. DNS Zone Transfer Counters

Counter

Description

AXFR Request Received

Total number of full zone transfer requests received by the DNS Server service when operating as a master server for a zone.

AXFR Request Sent

Total number of full zone transfer requests sent by the DNS Server service when operating as a secondary server for a zone.

AXFR Response Received

Total number of full zone transfer requests received by the DNS Server service when operating as a secondary server for a zone.

AXFR Success Received

Total number of full zone transfers received by the DNS Server service when operating as a secondary server for a zone.

AXFR Success Sent

Total number of full zone transfers successfully sent by the DNS Server service when operating as a master server for a zone.

IXFR Request Received

Total number of incremental zone transfer requests received by the master DNS server.

IXFR Request Sent

Total number of incremental zone transfer requests sent by the secondary DNS server.

IXFR Response Received

Total number of incremental zone transfer responses received by the secondary DNS server.

IXFR Success Received

Total number of successful incremental zone transfers received by the secondary DNS server.

IXFR Success Sent

Total number of successful incremental zone transfers sent by the master DNS server.

If your network environment is fully Active Directoryintegrated, the counters listed in Table 35.6 will all be zero.

Monitoring AD Replication

Measuring AD replication performance is a complex process because of the many variables associated with replication. They include, but aren't limited to, the following:

  • Intrasite versus intersite replication

  • The compression being used (if any)

  • Available bandwidth

  • Inbound versus outbound replication traffic

Fortunately, there are performance counters for every possible AD replication scenario. These counters are located within the NTDS object and are prefixed by the primary process that is responsible for AD replicationthe Directory Replication Agent (DRA). Therefore, to monitor AD replication, you need to choose those counters beginning with DRA.


Using Server Performance Analyzer 2.0

Server Performance Analyzer 2.0 (SPA 2.0) is a new tool from Microsoft that integrates with Server 2003 and comes preconfigured to analyze common roles for Windows servers. The tool is downloadable from Microsoft.com and must be installed on a server running some version of Windows Server 2003. This tool is invaluable for server sizing, education, and troubleshooting performance issues. It presents data that could be obtained through multiple other methods in an easy-to-read and understand format. Perhaps the most useful feature is the overview at the beginning of the report. It presents a sunny/cloudy/rainy graphical representation of server health in key areas such as memory utilization, processor use, and disk I/O.

After you download it, double-click the msi package to install the tool. Be sure to choose locations with adequate storage for data and reports. Click Finish to complete the installation. A reboot is not required. The program will be available at the root level of the program submenu under the Start menu.

Click the left column to expand the configuration menu. Here, you can choose and customize the server roles you would like to analyze for this server. System Overview is chosen by default. It offers only the most basic information and is often included as a subset of other roles.

To add a role, click the File menu and choose Add/Repair Data Collector Groups. You'll see six options. The most often used is Server Roles. This option will allow you to select basic server roles with preconfigured counters and preset thresholds for performance recommendations. A more advanced method would be to select IT Study Roles, which allow more in-depth monitoring on a larger scope of server roles. You can also create custom roles based on your own needs. Right-click Data Collectors and Reports and choose New/Data Collector Group. You can now customize every portion of the test from trace providers to counters. Basic tests will take 100 seconds to complete, while longer tests may take 5 minutes or more.

To run a test, select the role you would like to evaluate and click the green start arrow. After the test is complete, a report will be generated with the results. The status can be seen in the status bar at the bottom of the application window. Report generation can often take longer than the tests themselves.

SPA 2.0 creates reports in a standard XML format that can be viewed natively within the tool console or with Internet Explorer. To access the current report for any given test, expand the reports item and select Current. Expand the menu until the most recent report is displayed and select it to view the full report. A sample report is shown in Figure 35.5.

Figure 35.5. A sample SPA 2.0 report.

[View full size image]

The report structure is fairly simple; however, it contains a large amount of data and is interactive. Some sections may say Top 4 of 10 and you can choose any number, up to the maximum to display for the section.


Using the Windows System Resource Manager

The Windows System Resource Manager (WSRM), a feature of Windows Server 2003 Enterprise or Datacenter Editions, allows administrators to gain additional control over applications and processes. More specifically, WSRM can be used to control application's or process' processor utilization, memory usage, as well as processor affinity. Policies can be created to set constraints or ceiling values for an application or process. For instance, a policy can be configured to allow ProcessA to use only 10% of the processor during specified times or at all times. The scheduling is managed by the built-in calendar function.

The WSRM utility, illustrated in Figure 35.6, offers an intuitive way to gain control over the system and optimize application and overall system performance. A default policy is automatically installed to manage any system-related services that may be running on the system. You can also create custom policies for specific applications.

Figure 35.6. The WSRM interface.

[View full size image]

A notable advantageous feature of WSRM is its capability to manage applications running under Terminal Services. WSRM can be used to prevent a potential rogue user session before the associated applications grab most of a server's resources or even lock out other sessions. When an application or process begins to exceed its resource allocation (specified in the WSRM policy), the WSRM service attempts to bring the resource usage of the process back within the specified target ranges.


Managing Patches

Microsoft is taking a proactive approach in maintaining reliability and availability with Windows Server 2003 by establishing measures to help you keep up to date with the latest service packs and updates.

Anyone who has administered a Windows system is probably aware of the importance of keeping up to date with the latest system upgrades, such as bug fixes, performance upgrades, and security updates. Service packs and updates are intended to ensure optimal performance, reliability, and stability. Updates are individual patches, whereas service packs envelope many of these updates into a single upgrade. The service packs themselves don't contain new features. Only core enhancements and bug fixes are a part of the service pack. This makes for a more reliable, more robust service pack that will most likely prevent you from losing reliability and availability.

Service packs also contain the following benefits:

  • They can detect the current level of encryption and maintain that version (such as 56-bit or 128-bit).

  • They usually don't have to be reapplied after you install a system component or service.

Updates are Microsoft's answer to quick, reliable fixes. They are convenient because you don't have to wait for the next service pack to get a problem fixed. Updates often address a single problem. They now contain built-in integrity checks to ensure that the update doesn't apply an older version of what already exists.

You can run the update from a command line using the hotfix.exe utility.

Automating Patch Management

Various patch automation solutions exist for the Windows Server 2003 network environment. All of them strive to keep you up to date with the latest service packs and updates without large administrative overhead.

Two of these solutions are provided by Microsoft. The first is Windows Update with the Automatic Updates service, and the other is Software Update Services (described next).

Windows Update is a Web-based service using ActiveX controls that scans a system to see whether any patches, critical updates, or product updates are available and should be installed. It presents a convenient and easy way to keep your system up to date. The downside, however, is that you still have to go to the Windows Update Web site (http://windowsupdate.microsoft.com/) and select which components to download and install. Moreover, using this process makes it difficult to control and manage which updates can safely be applied to clients and servers.

Windows Automatic Update

As you can probably already tell, the Windows Automatic Update method of keeping up with service packs and updates can be beneficial to Windows network environments, but it's not true patch automation. Users or administrators still need to tend to each system and download the appropriate components. This method also has a few other limitations; for example, it doesn't allow you to save the update to disk to install later, there are no mechanisms to distribute updates to other systems, and there isn't administrative control over which updates are applied to Windows systems throughout the organization's network infrastructure.

The Windows Software Update Services is a logical extension of Windows Update that helps solve the automation problem while maintaining a greater level of control for the organization's IT personnel. It is a tool designed specifically for managing and distributing Windows service packs and updates on Windows 2000 and higher systems in an AD environment.

The Software Update Services consists of a Windows Server 2003 server preferably located within a DMZ and a client-side agent or service. The update server receives service packs and updates directly from Microsoft's public Windows Update Web site at scheduled intervals, and then they are saved to disk. Administrators can then test the service packs and updates before approving them to be distributed throughout the network. The path that the update takes from here depends on how the Windows Software Update Server is configured. After they are approved, service packs and updates can be pushed out at predefined intervals through a Group Policy Object (GPO) to client and server systems, systems can jump on the intranet and manually download updates, or the updates can be distributed to other servers that will eventually push the updates out to systems through the network environment. The latter option is extremely beneficial to larger companies or organizations because it distributes the workload so that a single server isn't responsible for pushing updates to every system.

Other benefits to using Software Update Services stem from the following management capabilities:

  • Software Update Services can be managed from a Web-based interface using Internet Explorer 5.5 or higher.

  • Synchronization with Software Update Services and the content approval process is audited and logged.

  • Statistics about update download and installations are kept.

Tip

For even more granular control and manageability over patch management automation, such as enhanced reporting functionality, evaluate Systems Management Server or a third-party product.


Summary

Although you can easily get caught up in daily administration and firefighting, it's important to step back and begin capacity-analysis and performance-optimization processes and procedures. These processes and procedures can minimize the environment's complexity, help you gain control over the environment, and assist you in anticipating future resource requirements.


Best Practices

  • Spend time performing capacity analysis to save time troubleshooting and fire-fighting.

  • Use capacity analysis processes to help weed out the unknowns.

  • Establish systemwide policies and procedures to begin to proactively manage your system.

  • After establishing systemwide policies and procedures, start characterizing system workloads.

  • Use performance metrics and other variables such as workload characterization, vendor requirements or recommendations, industry-recognized benchmarks, and the data that you collect to establish a baseline.

  • Use the benchmark results only as a guideline or starting point.

  • Use Task Manager to quickly view performance.

  • Use performance logs and alerts to capture performance data on a regular basis.

  • Consider using Microsoft Operations Manager or third-party products to assist with performance monitoring, capacity and data analysis, and reporting.

  • Carefully choose what to monitor so that the information doesn't become unwieldy.

  • At a minimum, monitor the most common contributors to performance bottlenecks: memory, processor, disk subsystem, and network subsystem.

  • Identify and monitor server functions and roles along with the common set of resources.

  • Examine network-related error counters.

  • Automate patch management processes and procedures using Software Update Services, Systems Management Server, or a third-party product.


Part XI: Integrated Windows Application Services

In This Part

CHAPTER 36 Windows SharePoint Services

CHAPTER 37 Windows Media Services


Chapter 36. Windows SharePoint Services

In This Chapter

  • The History of SharePoint Technologies

  • Identifying the Need for Windows SharePoint Services

  • Installing Windows SharePoint Services

  • Exploring Basic Windows SharePoint Services Features

  • Exploring End User Features in WSS

  • Customizing and Developing WSS Sites

Windows Server 2003 has already established itself as a robust, capable operating system loaded with a rich set of features. Built-in tools and services provide for a wide range of functionality unsurpassed in other products and older versions of Windows. In addition to these capabilities, Windows Server 2003 also contains native support and licensing for additional services that can be freely downloaded, installed, and supported. One of these tools is Windows SharePoint Services (WSS).

With the new version of SharePoint technologies, Microsoft introduces what it considers to be the next-generation platform for file sharing and collaboration. There is a great deal of confusion today about the exact nature of SharePoint. This confusion is based on the fact that SharePoint Technologies are composed of two distinct products: Windows SharePoint Services, the focus of this chapter, and a separate application called SharePoint Portal Server 2003.

This chapter focuses on how Windows SharePoint Services can be effectively used to extend the functionality of Windows Server 2003. The history and capabilities of WSS are described, and generic design and installation options are explained. Key differences between WSS and the full Portal product, SharePoint Portal Server 2003, are also outlined and explained. Updates to Windows SharePoint Services in Windows Server 2003 R2 are described and the installation of WSS is covered, along with a demonstration of base functionality.


The History of SharePoint Technologies

Windows SharePoint Services has a somewhat complicated history. Multiple attempts at rebranding the application and packaging it with other Microsoft programs has further confused administrators and users alike. Consequently, a greater understanding of what WSS is and how it was constructed is required.

WSS's Predecessor: SharePoint Team Services

In late 1999, Microsoft announced the digital dashboard concept as the first step in its knowledge management strategy, releasing the Digital Dashboard Starter Kit, the Outlook 2000 Team Folder Wizard, and the Team Productivity Update for BackOffice 4.5. These tools leveraged existing Microsoft technologies, so customers and developers could build solutions without purchasing additional products. These tools, and the solutions developed using them, formed the basis for what became known as SharePoint Team Services, the predecessor of Windows SharePoint Services.

With the launch of Office XP, SharePoint Team Services was propelled into the limelight as the wave of the future, providing a tool for non-IT personnel to easily create Web sites for team collaboration and information sharing. Team Services, included with Office XP, came into being through Office Server Extensions and FrontPage Server Extensions. The original server extensions were built around a Web server and provide a blank default Web page. The second generation of server extensions provided a Web authoring tool, such as FrontPage, for designing Web pages. Team Services was a third-generation server extension product, with which a Web site could be created directly out of the box.

Understanding the Original SharePoint Portal Server

A full understanding of the WSS product is not achieved without understanding its companion product, SharePoint Portal Server (SPS). SharePoint Portal Server further extends the capabilities of WSS, allowing for the creation of an enterprise portal platform. Although the paths of the two product lines have converged, the origins of SPS were originally separate from those of WSS.

In 2001, Microsoft released SharePoint Portal Server 2001. The intent was to provide a customizable portal environment focused on collaboration, document management, and knowledge sharing. The product carried the "Digital Dashboard" Web Part technology a step further to provide an out-of-the-box solution. SharePoint Portal was the product that could link together the team-based Web sites that were springing up.

Microsoft's initial SharePoint Portal product included a document management system that provided document check-in/check-out capabilities, as well as version control and approval routing. These features were not available in SharePoint Team Services. SharePoint Portal also included the capability to search not only document libraries, but also external sources such as other Web sites and Exchange Public Folders.

Because the majority of the information accessed through the portal was unstructured, the Web Storage System was the means selected for storing the data, as opposed to a more structured database product such as SQL, which was being used for SharePoint Team Services. The Web Storage System, incidentally, is the same technology that is used by Microsoft Exchange. Further SharePoint implementations use the same SQL database as WSS does, however.

Differences Between SharePoint Products

As SharePoint Team Services was available at no extra charge to Office XP/FrontPage users, many organizations took advantage of this "free" technology to experiment with portal usage. Team Services's simplicity made it easy to install and put into operation. Although functionality was not as robust as a full SharePoint Portal Server solution, knowledge workers were seeing the benefits of being able to collaborate with team members.

Adaptation of SharePoint Portal Server progressed at a slower rate. In a tight economy, organizations were not yet ready to make a monetary commitment to a whole new way of collaborating, even if it provided efficiency in operations. In addition, the SharePoint Portal interface was not intuitive or consistent, which made it difficult to use.

Having two separate products with similar names confused many people. "SharePoint" was often discussed in a generic manner, and people weren't sure whether the topic was SharePoint Portal or SharePoint Team Services, or the two technologies together. Even if the full application name was mentioned, there was confusion regarding the differences between the two products, and about when each was appropriate to use. People wondered why SharePoint Team Services used the SQL data engine for its information store, while SharePoint Portal Server used the Web Storage system. It appeared as though there was not a clear strategy for the product's direction.

Microsoft's Current SharePoint Technology Direction

Microsoft took a close look at what was happening with regard to collaboration in the marketplace and used this information to drive its SharePoint technologies. Microsoft believed that in today's world of online technology and collaboration, people need to think differently about how they work. The focus was to develop a suite of products to better handle this collaboration.

In addition to looking closer at how people collaborate, Microsoft also analyzed what had transpired with its SharePoint products. The end result was that Microsoft modified its knowledge management and collaboration strategy. Microsoft began talking about its "SharePoint Technology," with a key emphasis on building this technology into the .NET framework, and thus natively supporting XML Web Services.

In the 2003 version of the SharePoint products, Microsoft developed Windows SharePoint Services as the engine for the team collaboration environment. Windows SharePoint Services replaces SharePoint Team Services, and it includes many new and enhanced features, some of which were previously part of SharePoint Portal Server. Windows SharePoint Services was also included as an optional component to the Windows Server 2003 operating system at the same time.

SharePoint Portal Server remains a separate server-based product. It builds on the Windows SharePoint Services technology and continues to be the enterprise solution for connecting internal and external sources of information. SharePoint Portal Server allows for searching across sites, and enables the integration of business applications into the portal.

The current version of SharePoint integrates more closely with Microsoft Office 2003, making it easier for users to personalize their experience. For example, users can create meeting and document workspaces directly from Office 2003 products. New and enhanced features also enable personalization and customization through the Web browser. Users no longer need administrator privileges to create a site, or to be a FrontPage or programming expert to personalize the site. Figure 36.1 shows some of the customization features that can be accessed from the browser.

Figure 36.1. Personal View customization features available from the browser.

[View full size image]

Collaboration is also enabled directly from Office 2003 applications. A SharePoint workspace can be accessed directly from Word and Excel 2003 using a special Shared Workspaces task pane. The task pane displays the members of the workspace, the status of the document, and tasks that have been entered into the workspace. This enables users to take advantage of SharePoint's collaboration features without leaving the comfort of their Office products.

New and enhanced deployment options have enabled organizations of any size to use SharePoint technologies, and to support a flexible user base.

Note

Windows Server 2003 R2 introduced an updated version of Windows SharePoint Services. This version, corresponding to WSS Service Pack 2, adds 64-bit server support, SQL 2005 database support, patches and fixes, and enhanced extranet functionality to Windows SharePoint Services. It is recommended to evaluate using this latest version because it provides for the most powerful WSS functionality in Windows Server 2003.


Identifying the Need for Windows SharePoint Services

Windows SharePoint Services is one of those applications that is greatly misunderstood. Much of the confusion over the previous branding of the product has contributed to this, but a fundamental shift in thinking is required to effectively utilize the platform. An understanding of what WSS is and how it can be fully utilized is an important step toward realizing the efficiency the system can bring.

Changing Methodology from File Servers to a WSS Document Management Platform

WSS expands beyond its origins as a Web team site application into a full-fledged documentation platform with the new functionalities introduced. These capabilities, previously only available with the full-functioned SharePoint Portal Server product, allow WSS to store and manage documents efficiently in a transaction-oriented Microsoft SQL Server 2000 environment. What this means to organizations is that the traditional file server is less important, and effectively replaced, for document storage. Items such as Word documents, Excel spreadsheets, and the like are stored in the WSS database.

Along with these document management capabilities comes the realization by users that their standard operating practice of storing multiple versions of files on a file server is no longer feasible or efficient. Using WSS effectively subsequently requires a shift in thinking from traditional approaches.

Enabling Team Collaboration with WSS

Windows SharePoint Services, and previously SharePoint Team Services, has demonstrated how Web-based team sites can be effectively used to encourage collaboration among members of a team or an organization. Content relevant to a group of people or a project can be efficiently directed to the individuals who need to see it most, negating the need to have them hunt and peck across a network to find what they need.

Once deployed, the efficiency and collaboration realized is actually quite amazing. A good analogy to SharePoint can be found with email. Before using email, it's hard to understand how valuable it can be. After you've used it, however, it's hard to imagine not having it. The same holds true for SharePoint functionality. Organizations that have deployed WSS or the full-functioned SharePoint Portal Server product have a hard time imagining working without it.

Customizing WSS to Suit Organizational Needs

If the default functionality in WSS is not enough, or does not satisfy the specific Web requirements of an organization, WSS can easily be customized. Easily customizable or downloadable Web Parts can be instantly "snapped-in" to a WSS site, without the need to understand HTML code. More advanced developers can use ASP.NET or other programming tools to produce custom code to work with WSS. Further enhancement of WSS sites can be accomplished using FrontPage 2003, which allows for a great deal of customization with relative ease. In general, if it can be programmed to work with Web Services, it can interface with WSS.


Installing Windows SharePoint Services

Installation of Windows SharePoint Services is a fairly straightforward activity that does not require any advanced configuration. Simply download the WSS installation package from Microsoft, perform any prerequisite activities, and install the application. More complex installations, such as those involving a full version of SQL Server, are not considerably more difficult. Before installation can begin, a suitable server environment must be chosen and the requirements for installing WSS must be outlined.

Outlining WSS Requirements

Any design of WSS should take into account the various hardware and software requirements in advance. The following is a list of Microsoft's minimum recommendations for a Windows SharePoint Systems server. It is important to note that this list indicates only the bare minimum necessary for support. In most cases, servers deployed for WSS will be more robust than the minimal requirements dictate.

Hardware and Software

  • Intel Pentium III-compatible processor or greater

  • 512MB of RAM or greater

  • 550MB of available hard disk drive space or greater

  • Windows Server 2003 Standard or Enterprise (R2 version recommended for the latest versions of WSS)

  • Internet Information Services (IIS) installed, with ASP.NET, SMTP, and WWW service

  • SQL Server (Standard/Enterprise) or Microsoft SQL Server 2000 Desktop Engine (MSDE or WMSDE)

Clients access WSS through a Web browser. Microsoft supports several different Web browsers for use with Windows SharePoint Services:

  • Microsoft Internet Explorer 5.x with Service Pack 2

  • Internet Explorer 6.0 or later

  • Netscape Navigator 6.2 or later

After these requirements have been satisfied, WSS can be installed on a Windows Server 2003 system.

Detailing Pre-installation Steps

After Windows Server 2003 has been installed and all prerequisites have been satisfied, the IIS components necessary for WSS to operate can be installed. The following steps detail how to install these items:

1.
Log in to the server as an account with local administrator privileges.

2.
Go to Start, Control Panel.

3.
Double-click on Add or Remove Programs.

4.
Click on Add/Remove Windows Components.

5.
Select Application Server and then click the Details button.

6.
Check ASP.NET in the list of components.

7.
Select Internet Information Services (IIS) and click the Details button.

8.
If needed, select the optional SMTP Service component as illustrated in Figure 36.2, click OK twice, and then click Next to continue.

Figure 36.2. Installing prerequisite IIS components.

9.
Insert the Windows Server 2003 CD if prompted and then click OK.

10.
Click Finish when the wizard completes.

At this point, the IIS installation process should be complete. To verify successful installation, the Configure Your Server log can indicate whether IIS installed successfully. If there were problems, the log will contain error information. If error conditions exist, they must be remedied or WSS might not function properly.

To further verify successful installation of IIS, open the IIS Services Manager (Start, Administration Tools, Internet Information Services [IIS] Manager). The IIS configuration should match Figure 36.3 on a new Windows Server 2003 installation. In this figure, the Web Service Extensions are displayed.

Figure 36.3. IIS Manager with Web Service Extensions.

[View full size image]

Updating and Patching a WSS Server

After the Windows Server 2003 software is installed and has been configured as an Application Server, the latest service packs and updates should be installed and verified. Because security vulnerabilities can severely cripple or disable a server, it's very important to keep the servers up to date with the latest patches. Only after the Windows Server 2003 updates and patches have been installed should Windows SharePoint Services be installed. This ensures that the server is up to snuff from a security standpoint and has the latest technology fixes installed.

The Windows Update tool is a good place to start in the process of updating and patching the new Windows Server 2003 system. Some organizations will have other ways of making the updates available, as they might have been already downloaded and can be installed or pushed from a Microsoft Windows Server Update Services (WSUS) server or an SMS (Systems Management Services) Server.

If SUS, SMS, or another software distribution system is not in place, the Windows Update Web site and tools make the Server OS updating process very easy. This process is essentially automated, and accessible by clicking on the Windows Update icon that appears in the Start menu, under All Programs. Selecting this option will connect to one of the Microsoft Windows Updates, or it can be typed into the browser (http://windowsupdate.microsoft.com).

Note

Internet Explorer Enhanced Security Configuration is enabled by default on new Windows Server 2003 installations. This will require the addition of new sites to the Trusted Sites Zone. When IE is opened and a URL is entered, an Internet Explorer message window will appear with additional information on this subject. The site being accessed can be added to the Trusted Sites Zone by clicking the Add button in this window, clicking the Add button in the next window, and then clicking the Close button. Although this is time consuming, it helps secure the server. IE Enhanced Security Configuration can be turned off by performing the following steps: Click Start, Control Panel, Add or Remove Programs, Add or Remove Windows Components, select Internet Explorer Enhanced Security Configuration, select Details, and uncheck For Administrator Groups, and/or for all other groups. Click OK, click Next, and when the process completes, click Finish.

Once at this site, choose the Scan for Updates option, which starts a quick scan of the local server and then updates the left pane with recommendations for the suggested critical updates, Service Packs, and Windows Server 2003 family and driver updates.

Caution

Although applying updates to a Windows Server 2003 system is a more reliable process than with previous versions of the server OS and less likely to result in problems with server functionality, they should be tested in a lab environment first and approved for use on the network before being implemented on a production Windows Server 2003 system.

After the patches and updates are installed, the windowsupdate.microsoft.com page provides a View Installation History option in the Windows Update pane, which lists the patches and fixes downloaded from the site. This list will not be 100% accurate if changes have been made to the items installed (for example, if one or more patches or updates have since been uninstalled), but provides a good record of what has been downloaded and the status of the installation. If one or more items failed to install, they may need to be reinstalled.

In addition, the updates can be viewed by accessing Start, Settings, Control Panel, Add or Remove Programs. Additional information on each item can be accessed by clicking once on the item, which brings up the option to remove the item from the server, as well as a hyperlink to support.microsoft.com and a Knowledge Base article with more technical information about a specific update.

Performing a Windows SharePoint Services Installation

The actual installation of WSS is a very straightforward process. There is one major decision that must be decided before the setup begins: whether to use the free Windows MS SQL Desktop Engine (WMSDE) version of SQL Server 2000, or to install to an already deployed instance of SQL Server 2000 Standard/Enterprise. The initial process detailed here indicates installation with the free WMSDE database, which can be used in small WSS implementations of less than 10 sites.

Prior to Windows Server 2003 R2, the WSS installation file needed to be downloaded from Microsoft. With R2, it can simply be installed by using Add/Remove Programs under the Control Panel applet. If R2 is not required, the installation software for WSS can be downloaded from http://www.microsoft.com/windowsserver2003/techinfo/sharepoint/wss.mspx and installed via the procedure outlined below.

Once downloaded, the installation process can be started by following these steps:

1.
Double-click on the STSV2.exe file to extract the installation files, and then allow them to be copied to the C drive.

2.
Check the box to accept the license agreement and click Next.

3.
Select Typical Installation as illustrated in Figure 36.4 and click Next to continue.

Figure 36.4. Installing WSS.

Note

If the WSS Server to be set up will be part of a server farm, or a group of many WSS servers working with the same content, you can install WSS without a local SQL database and use the farm's SQL database instead. This method can be useful if load-balancing this server with multiple WSS servers.

4.
Click the Install button after verifying that Setup will install WSS.

At this point, the Setup Wizard will copy files and install WSS to the local server. After installation, Setup will open an Internet Explorer window and inform you that IIS will need to be restarted.

5.
Click Start, Run, type cmd.exe, and press Enter to open a command-prompt window.

6.
Type iisreset to restart IIS, as illustrated in Figure 36.5.

Figure 36.5. Restarting IIS after WSS installation.

[View full size image]

Setup will then run and install Windows SharePoint Services. After it's installed, it is important to update WSS with the latest service pack, particularly because SP2 for WSS includes updates that allows WSS to utilize SQL 2005 for the back-end data store. After installation and updating, Internet Explorer can be opened from the server and pointed to the local machine (http://localhost). Because Windows SharePoint Services will be installed on the default Web server, a new Windows SharePoint Services Web site should appear, as illustrated in Figure 36.6.

Figure 36.6. New WSS Site.

[View full size image]

Note

If Windows SharePoint Services needs to utilize an existing full SQL Server 2000 instance (or simply one already installed on the server itself), the setup for WSS will need to be run in a slightly different manner. Extract the files to a location on the hard disk by running the STSV2.exe executable and canceling Setup. You can then set up WSS from the command prompt with the following syntax at the command prompt (assuming the files have been extracted to the C:\ drive):

C:\program files\sts2setup_1033\setupsts.exe remotesql=yes

Run Setup as normal, except for choosing Server Farm from the options listed in Figure 36.4.


Exploring Basic Windows SharePoint Services Features

After WSS is installed, the system can be used to create Web sites, manage documents, and provide other capabilities. Understanding and testing the features available in WSS is an important prerequisite step toward effectively using Windows SharePoint Services, and a walkthrough of those features should subsequently be performed.

The next sections will walk through the features that are readily available to an employee using Microsoft Word 2003 when Windows SharePoint Services is installed on the network. Note that Shared Workspaces can be created from other Office 2003 applications, including Excel, PowerPoint, and Visio.

Creating a Shared Workspace from Microsoft Word

When a document is opened or created in Word 2003, the Tools menu provides the option of a Shared Workspace, and when selected, the Shared Workspace interface appears on the right side of the screen. The user is prompted to name the workspacethe default is the document nameand choose a SharePoint site where the workspace will reside. The user can then add members to the site by entering either a domain and username, an email address, or both to define who will be included in the workspace. The level of participation for those members can also be set on the site with varying levels of authority, such as Reader, Contributor, Web Designer, or Administrator.

Six tabs in the Shared Workspace area provide information and tools to the user who created the site, as well as other users who open the file:

  • Status Provides errors or restrictions regarding the file.

  • Members Provides a list of the different members of the workspace, and whether they are online.

  • Tasks Allows the user to view tasks assigned to members of the site or create new ones.

  • Documents Displays any other documents or folders available in the workspace, and allows the addition of other documents or folders to the workspace.

  • Links Displays any URL links on the site and allows the addition of new URL links to the workspace.

  • Document Information Displays basic information about the file such as who created or edited it, and allows viewing of the revision history.

These features give the user a "dashboard" providing valuable information about the document, and helps other users collaborate on the document.

Tip

Online presence can be enabled on a virtual server basis when Office 2003, Live Communications Server 2003, and the latest version Windows Messenger software is installed. Person Name Smart Tags become active when the mouse pointer is hovering over a site member's name. Additional tools are made available when the down arrow is clicked, such as a notification as to whether the person is online or available for instant messaging. Other options include Schedule a Meeting, Send Mail, or Edit User Information.

With this basic functionality, a Word user can create in minutes a customized work environment that includes other employees and can include other key documents. This ease of use will go a long way in speeding adoption of Windows SharePoint Services.

Working Within the Windows SharePoint Services Site

By clicking on the Open Site in Browser link, the individual will see the workspace open up in their browser (see Figure 36.7) and this opens up a whole new range of features that display the power of Windows SharePoint Services.

Figure 36.7. The Windows SharePoint Services workspace.

[View full size image]

Note

Note that if network users simply double-click on the file to open it from a network folder, or open it from within a Word session, they will be informed that the document is part of a workspace and asked whether they want to update the document they are opening based on the information available from the workspace. This feature ensures that anyone who uses the document becomes aware that it is connected to a workspace and can access this site if they like.

The default workspace appears in a browser window that shows the location of the file in the Address area of the browser and, below that, a customized SharePoint menu bar. The default components of the site that appear in the Quick Launch bar are as follows:

  • Documents

  • Pictures

  • Lists

  • Discussions

  • Surveys

The rest of the page provides space for the Web Parts, which by default are as follows:

  • Announcements

  • Shared documents

  • Tasks

  • Members

  • Links

The administrator of the workspace, along with a member of the site in the capacity of contributor or Web designer can easily modify the contents of the workspace by selecting Modify Shared Page, found in the upper-right corner of the page, and then selecting the Design This Page option. For more adventurous or experienced users, new Web Parts can be selected and added to the workspace.

Through this process, a Web page can quickly be created that contains the document that the end user wants to share with other co-workers, as well as be expanded to include other resources for collaboration purposes. This creates a browser-based working environment, and that provides a wealth of additional tools and capabilities for document management and collaborative efforts. For example, the creator of this new site can choose which users or groups to grant access to, and limit their capabilities to add, change, or delete items stored within the site. She can then assign tasks to these users related to the goals of the site, and these tasks will show up in the Shared Workspace pane when the document is opened in Word 2003.

Understanding Document Libraries

Document libraries may well be the feature most often used, as it is the location where documents and folders can be stored and managed, and document libraries offer a number of features not available in a standard server file share.

The team members who are working on the original document ("Windows 2000 Server Upgrade SOW r5" in this case) can upload related documents to this library for reference purposes. This eliminates the step of printing out copies of supporting documentation for an in-person meeting, or emailing the actual files or hyperlinks via email.

A number of actions can be performed on the document from the Shared Documents page, as shown in Figure 36.8.

Figure 36.8. Available actions at the Shared Document page.

[View full size image]

Tip

Libraries include an Explorer View by default that enables you to work with files in the library similar to the way in which you work with files in Microsoft Windows Explorer. In Explorer view, files and folders can be deleted, renamed, copied, and pasted from the desktop. Multiple files and folders can be selected to be deleted, moved, or copied, as well. This capability allows users to use tools and processes they are already familiar with to manage their documents in Windows SharePoint Services libraries. To use Explorer view, a Windows SharePoint Servicescompatible client program such as Microsoft Office 2003 and Microsoft Internet Explorer 5 or later must be installed.

  • View Properties Show the document filename and title assigned to the document (if any), who created the document and when, as well as who modified the document and when.

  • Edit Properties The name of the file that SharePoint is storing and the title of the document can be changed here.

  • Edit in Microsoft Word If the user has editing rights in the Shared Document library, the document can be opened and edited in Microsoft Word. Note that if the document is a Microsoft Office document, the appropriate application will be listed, such as Excel or PowerPoint.

  • Delete If the user has deletion rights in the Shared Document library, the file can be deleted.

  • Check Out When a document is checked out, it is reserved for the individual who has checked it out, and only that person can modify the document. So even if that person doesn't have the document open, no one else can edit it. An administrator of the site can force a document check-in.

  • Version History Allows the user to see any other versions of the document, which can be opened or viewed, and to see any comments that were added by other site users to those versions. Old versions can also be deleted if the user has the right to do so.

  • Alert Me The user can choose to have an alert emailed if changes are made to the file.

    Note

    Alerts are an extremely powerful feature in Windows SharePoint Services. A user can set an alert on an individual item stored in a SharePoint list, such as a document, so that if the document is changed, users receive an email letting them know of the change. Alternatively, an alert can be set for the whole document library, so if any items are changed, added, or deleted, users receive an email. The emails can be sent immediately, or in a daily or weekly summary. This is the primary way the Windows SharePoint Services pushes information to the users of its sites, enhancing the flow of information.

  • Discuss When selected, this option opens the document in Word or another supported Microsoft Office application and allows the creation of notes that are attached to the document to facilitate collaboration. These conversations are stored outside the document and help time-stamp and record the thoughts of different participants without modifying the contents of the document itself.

  • Create Document Workspace This is the same process that was used to create the initial workspace, and would be redundant in the case of this example, because it would create a workspace within a workspace. But for other documents posted in a library, this enables a user to create a workspace dedicated to one specific document.

Other capabilities in the Shared Documents page include creating a new document, uploading other documents to the site, creating a new folder, filtering the documents, or editing the list in a datasheet.

Using Picture Libraries

A picture library can include a wide variety of file types, including JPEG, BMP, GIF, PNG, TIF, WMF, and EMF. Examples would be photos of members of the team, or screenshots of documents from software applications that might not be available to all users. For instance, a screen capture from an accounting application could be saved to the library in BMP format so that any of the users of the site could see the information.

Similarly, a Visio diagram or Project Gantt chart could be saved to one of these formats, or as an HTML file and then saved to a picture library and thereby made accessible to users of the site who might not have these software products installed on their workstations. By providing a graphical image rather than the native file format, the amount of storage space required can be reduced in many cases, and there is no easy way for users to change the content of the documents.

Maps of how to find a client's office or digital photos of white boards can also be included. Some editing features are available using the Microsoft Picture Library tool (if Office 2003 is installed), which include brightness and contrast adjustment, color adjustment, cropping, rotation and flipping, red-eye removal, and resizing.

Pictures can be emailed directly from the library, or a discussion can be started about a photo as with other documents in libraries. Pictures can be sorted using the filter tool by file type, viewed in a slideshow format, checked out for editing, the version history can be reviewed, or alerts can be set.

Although this type of library may not be useful in every collaborative workspace, it provides a set of tools that are well suited to newsletter creation, complex document publication, or less formal uses, such as company events.

Working with SharePoint Lists

Lists are used in many ways by WSS, and a number of the Web Parts provided in the default workspace site are in fact lists. The following lists can be created:

  • Links These lists can contain either internal or external URL links, or links to networked drives.

  • Announcements These lists typically contain news that would be of interest to the employees accessing the site, and can be set to expire at predefined times.

  • Contacts Contacts can be created from scratch using the provided template, or can be imported from Outlook. This type of list can help clarify who is involved with a particular project or site, what their role is, how to contact them, and can contain custom fields.

  • Events Events can be created in the site complete with start and stop times, descriptions, location information, and its rate of recurrence. The option to create a workspace for the event is provided when it is created. Events can be displayed in list format or in a calendar-style view. Events can be exported to Outlook, and a new folder will be added to the calendar containing the events. Note that this calendar will be read-only in Outlook.

  • Tasks Each task can be assigned to a member of the site and can have start/due dates and priority levels set, and the percentage complete can be tracked. These tasks do not link to Outlook, however, so they're specific to the SharePoint site.

  • Issues Slightly different from tasks, issues include category references, and each receives its own ID number. Individuals assigned to an issue can automatically be sent email notification when an issue is assigned to them, and will receive emails if their assigned issue changes.

  • Custom List If one of the template lists doesn't offer the right combination of elements, one can be created from scratch. This allows the individual creating the list to choose how many columns make up the list, determine what kind of data each column will contain, such as text, choices (a menu to choose from), numbers, currency, date/time, lookup (information already on the site), yes/no, hyperlink or picture, or calculations based on other columns. With this combination of contents available and the capability to link to other data contained in the site from other lists, a database of information that pertains to the site can be created that can get quite complex. For example, a custom list could include events from the Events list, tracking the cost of each event and which task corresponds to the event.

  • Data imported from a spreadsheet Rather than creating a list from scratch, data can be imported from a spreadsheet (ideally Excel). The data can then be used actively within the site without the file needing to be opened in Excel. It can then be exported for use in other applications.

With any list, there are additional options available to users of the site. Figure 36.9 shows a simple task list open in Datasheet view (Office 2003 is required for this feature), as well as the additional options available when the Task Pane option is selected.

Figure 36.9. Datasheet view task options.

[View full size image]

After the list is displayed in Datasheet view, new rows can be added by either selecting this option in the tool bar, or by clicking in the row that starts with the asterisk. Totals of all columns can be displayed by clicking the Totals option. By selecting the Task Pane option, the tools shown in Figure 36.9 in the Office Links area become available, including exporting or linking to Excel, printing, charting, creating a pivot table in Excel, or exporting, creating a linked table of reporting with Access.

Using SharePoint Discussions

The next option in the Quick Launch bar is for discussions, which are a key component for online collaboration. Although email is well suited to conversations involving a handful of people, it becomes unwieldy when there are too many participants, as multiple threads of conversations can easily get started and the original point of the discussion can get lost. With a bulletin board or threaded discussion, the high-level topics can be viewed at the same time, readers can choose the topics of interest, and can see any responses to the initial item. With email, individuals have no control over which emails they receive, while a discussion Web Part in SharePoint allows the user to decide what items to read and which ones to respond to.

Members with the appropriate rights can also manage the discussions to remove topics or responses that are not appropriate to the discussion, or remove threads when they have been completed. This level of control facilitates effective communication and encourages participation by the various team members.

Figure 36.10 shows a sample of a discussion concerning a proposal that is about to be sent out. The paperclip icon on the top-level posting indicates that the actual document is attached for review. Two other users of the site have posted their responses.

Figure 36.10. Sample discussion board.

[View full size image]

Discussions can also take place on any Office document posted to a SharePoint site. The data is stored in the SharePoint database, not in the document itself. This encourages team members to share their input and thoughts about a document in a controlled environment that is directly associated with the document.

Depending upon which site group participants are members of, they may only be able to view threaded discussions, or they may be able to participate, edit, and even delete portions of the conversation.

The alerts feature is very useful with discussions, as users can choose when and if they want to be alerted about changes to a specific discussion thread. This eliminates the need for participants to check a number of different discussions on a regular basis, as they can receive an email informing them if changes have been made.

Understanding Surveys

An entry for surveys also appears in the Quick Launch area in the Document Workspace. With Windows SharePoint Services, it's easy to quickly create a survey to request input from site users on any number of topics. They can be configured to request input on any topic imaginable, such as the functionality of the site, the information contained in it, or any business-related topics. As well as collecting the information from the surveys, the results can be viewed individually, displayed graphically, or exported to a spreadsheet for further analysis.

Surveys can be configured to be anonymous, so no information is saved or provided about the individual who responds to the survey, or the information can be displayed. Additionally, both multiple responses and single responses are possible. Other options include allowing survey users to see other responses or only their own, or allowing them to edit their own and others' responses (or none at all). Common sense would dictate that users should not be able to edit a survey once it's submitted, but in some situations it may make sense to allow a person to go back and change input at a later date.


Exploring End User Features in WSS

The previous version of Windows SharePoint Services brought confusion to end users. The user interface was inconsistent, and it was difficult to maneuver between pages. For example, some pages had a Back button, some had menu items on the page that you could click and go back to, and some had nothing to get you "back," and you had to use the browser's Back feature or type in the URL to get back to where you wanted to go. In addition, there were some functions that had to be performed outside of WSS, some could only be done from within, and some could be done either way.

Windows SharePoint Services has a better user interface, and also has tighter integration with Microsoft Office 2003. A user working on a document in Word 2003 can decide that collaboration is necessary and create a shared workspace, invite users to participate, and set up some milestone tasks without ever leaving Office 2003.

Windows SharePoint Services provides the end user with a much better set of features for customizing and personalizing sites. Users can create their own personal sites containing their own documents, their own links, and other content that is meaningful to them, as opposed to having to live with a "generic" Web site with "generic" content that may not be applicable to their position in the organization.

Some of the new and improved features available for enhancing the end user experience are discussed in the following sections.

Expanding Document Management Capabilities

Previously, the full SharePoint Portal Server had to be used if any kind of document management was required, such as controlling document revisions through check-in/check-out, and version control. Realizing that these features are desirable for any type of document collaboration environment, Microsoft moved many of the document management features into the base Windows SharePoint Services environment. Now included in Windows SharePoint Services are features such as the following:

  • Document check-in/check-out to ensure that revisions are not overwritten by another user

  • Maintaining versions of documents for tracking changes

  • Ability to require approval when checking a document back in for quality control

In addition to these changes, Windows SharePoint Services provides the user with the flexibility to create a structured document storage environment, as opposed to the relatively flat view of the document space in older versions. Windows SharePoint Services is also more tightly integrated with Microsoft Office 2003, providing enhanced features available directly from the Office interface. Features in these areas include the capability to

  • Create folders within a document library, and view all documents in a library, including those in subfolders.

  • Create a Windows SharePoint Services document workspace directly from Word 2003, providing a means for easily setting up collaboration sites.

  • Easily save and retrieve SharePoint documents from Office 2003 applications. Working with SharePoint 2001 and Microsoft Office provided a challenge for IT and for the individuals who tried to use Office as the jumping-off point for collaboration. Improvements in Microsoft Office 2003 and Windows SharePoint Services make saving documents to a workspace as easy as saving them to a file share.

  • Access document libraries in the same manner as file shares through HTTP DAV Web Folder support, preventing users from having to learn a whole new set of commands.

  • View Office documents through the browser without having Office installed on the client computer. This enables the remote and mobile user to view documents stored in SharePoint when on the road from a client's computer, when sitting at an airport kiosk, or when having a cup of coffee at an Internet café.

Introducing Meeting Workspaces

When organizations have meetings, there is generally an agenda for the meeting, some type of document or documents associated with the meeting, and often follow-up tasks. Although email can be used to send out agendas and documents prior to the meeting, and to send out follow-up tasks and meeting notes, a better solution would be to have all of the information associated with the meeting available in one place. Meeting workspaces, new in Windows SharePoint Services, provide this capabilitya place for managing all of the documentation and tasks associated with a meeting. Meeting workspaces can be created from the site or from the "schedule meeting" function in Outlook 2003. When a meeting is scheduled using Outlook 2003, an option is available for creating a Windows SharePoint Services meeting workspace to store the meeting agenda, a list of attendees, documents relevant to the meeting, and any action items that result from the meeting.

There are several meeting templates available when creating the meeting workspace. In addition to a "standard" single meeting workspace, the other types of meeting workspaces include the following:

  • Decision meetings

  • Social meetings

  • Multiple meetings

Figure 36.11 shows the different templates that can be chosen when creating a new site.

Figure 36.11. Templates for new SharePoint sites.

[View full size image]

Taking Advantage of Personal Sites

A special site called My Site is available to WSS users to customize. This site has a view that only the creator can see (the personal view) and one available to the other users (the public view). The personal view can be used for storing personal documents, tasks, and links, and the public view can be used to push information to other users. Content can be pushed to My Site based on the owner's audience.

User profile information can be updated from My Site, and a list of documents created by the user or owner of the site can be viewed. (This list can also be displayed under the title Documents By This User in the user's profile.) The My Links Web Part can be used to add links to items that are either inside or outside the site. Search queries can also be added. The My News Web Part enables the user to view targeted news content on the Home Page. There are also Web Parts for adding Exchange 2000 and Exchange 2003 Inbox, Task, and Calendar views to My Site.

Integrating with Microsoft Office 2003

A key design goal for Windows SharePoint Services was to have it more tightly integrated with Microsoft Office. Although Windows SharePoint Services technologies support earlier versions of Office, improvements and enhancements in Microsoft Office 2003 provide a more efficient way for users to access shared document workspaces and team sites. This ease of use for accessing information encourages users to share, collaborate, and communicate together on projects, initiatives, or ideas. For example, instead of simply opening up a document in Microsoft Office 2000 and working on the document, a user opening the same document off a SharePoint server with Microsoft Office 2003 is presented with not only the document, but also a new task pane that lists the members of the team site where the document is stored (in Instant Messenger format), the status of the document, as well as any tasks and links associated with the document. Figure 36.12 is an example of what the new Microsoft Office 2003 Shared Workspace task pane looks like.

Figure 36.12. Shared Workspace task pane showing the Word 2003 Shared Workspace.

[View full size image]

Specifically, Microsoft Office 2003 integration means that

  • The entire setup of the document workspace can be done from the Word 2003 interface. Using the Shared Workspace task pane, the document workspace can be created, users granted access, links pertaining to the document added, and tasks created.

  • The document workspace is accessible through the task pane whenever the document is opened in Word 2003. The status of the members is displayed (such as whether they are online); messages can be sent to the members, links browsed to, and tasks viewed and updated.

  • When a meeting is created using Outlook 2003, a SharePoint meeting workspace can also be created for storing content related to the meeting.

  • SharePoint Contacts can be viewed directly from Outlook 2003.

Note

Even though SharePoint Contacts can be viewed in Outlook 2003, they are not truly "integrated" into Outlookthere is no automatic synchronization between SharePoint and Outlook 2003. The SharePoint contacts are treated as a separate contact list and are read-only when accessed from Outlook 2003.

  • Metadata and file properties are copied from Office documents to SharePoint librariestherefore file information doesn't have to be re-entered into SharePoint if it has already been entered in Office.

  • SharePoint documents can be attached to mail messages as shared attachments. When the user receives the message, there is a link to the workspace where the shared attachment can be accessed.

  • WSS sites can be searched from the Office 2003 Research and Reference tool pane.

  • Documents stored in SharePoint picture libraries can be edited with a new Office 2003 picture editing tool.

Personalizing Windows SharePoint Services

In addition to having a personal site, Windows SharePoint Services includes many ways in which users can personalize a SharePoint environment. Some forms of personalization can originate from Office 2003, and some features are accessed directly through WSS. The following list includes various ways in which users can personalize the SharePoint experience:

  • Users can create private sites and private views with their own personalized look and feel, in a way that makes sense for the way they work. Changes to team sites are stored with the user's profile and will be applied each time the user visits the site.

  • News can be targeted to users based on their audience affiliation. Considering the amount of information available, this is an efficiency feature that streamlines the content based on user interest.

  • Users can be given the capability to create sites without involving IT personnel. A typical scenario in today's world, where the organization does not have a portal application such as WSS, might go something like this:

    A user decides that a Web site would be helpful for collaborating on a project. The user presents the justification of the Web site to and obtains the approval of the department manager. The department manager submits a request to the IT department to have the site created. The IT manager reviews the request and places it low on the priority list because it will take time to develop the site, and the users can collaborate in the current environment using email and shared network drives. By the time IT gets to the project, the users have already completed the work and no longer need the collaboration site.

    If users can create shared sites and workspaces on their own, and don't have to wade through the red tape of getting IT personnel to create them, they will be more likely to use them and realize the benefits they can provide.

Taking Advantage of Lists

Each list in Windows SharePoint Services is a Web Part; therefore, they can be easily customized from the browser. Lists have been enhanced in many ways, including support for additional field types such as rich text, multivalue fields, and calculated fields. Field values can also be calculated. Field types can be changed after the list has been created, thus providing a means for accommodating data that is not particularly stable.

Windows SharePoint Services also has many new options for viewing lists. Filtered list views can also be created based on a calculation. For example, all events within the next week can be viewed by setting up a filter based on the date being greater than the current date plus seven. Another new view is the Event Calendar view, which enables displaying any list that has a date and time field in it using the daily, weekly, or monthly calendar view. Aggregated views enable totaling data into a number field and displaying the value. Totals can be based on the entire view or a subset of it. Group-by views enable grouping by one column, and then sorting within each group.

A picture library is a new kind of list. Graphics and photos can be stored in a picture library and optionally viewed as a filmstrip or as thumbnails in views automatically generated by SharePoint.

For Microsoft Office 2003 users, lists can be edited in Datasheet view. This option presents the data in spreadsheet style, and provides spreadsheet types of editing features, such as copy and paste, adding rows, and fill options. Using the Datasheet view can be faster then the traditional SharePoint list editing style for some types of data entry and editing.

Windows SharePoint Services includes new security features for lists. Permissions can be applied to the list so that only specific people can change it. Also included is the capability for the list owner to approve or reject items that are submitted to the list.

Other new list features include the following:

  • Users can create their own personal lists that are not visible to other users.

  • Alert notifications for lists include the name of the user that made the change to the list and which item in the list was changed.

  • The capability to add and remove attachments from a list item.

  • The capability to set up recurring events on an event list.

Improving on SharePoint Alerts

Alerts in Windows SharePoint Services are what used to be called notifications in previous versions. Alerts have been improved to identify whether the alert was sent because content was changed or added, and now include the tracking of additional items. Prior versions of SharePoint tracked search queries and documents. In addition to these items, Windows SharePoint Services alerts track

  • News listings

  • Sites added to the Site Directory

  • SharePoint lists and libraries

  • List items

  • WSS site users

  • Backward-compatible document library folders

Microsoft Outlook 2003 can be used to view Windows SharePoint Services alerts, and it includes rules to sort and filter them into special folders.

Exploring Additional New/Enhanced End User Features

There are many other new and enhanced features that improve the end user experience. These include the following:

  • A Site Directory that lists all WSS sites.

  • The capability for users to create a SharePoint site from the Sites Directory page, to indicate whether they want the site added to the directory, and whether they want the site content to be indexed. This provides a level of security for protecting sensitive information, such as human resources data.

  • Support for multiple file uploads. Older versions required files to be uploaded individually. Windows SharePoint Services supports multiple file uploads (such as an entire directory or folder). This is a great timesaver for organizations that are migrating large numbers of documents to SharePoint.

  • The capability to select from one of several site templates when creating a new site. Organizations can also create their own site templates (such as with the organization logo and color theme) for providing a level of consistency among different types of sites within the site.

  • The capability to create surveys and have the results automatically calculated and made available.

  • Additional improvements in the survey process. The survey feature now supports responding to a question using a scale, and the capability for users to select all answers that may apply to a survey question.

  • Everywhere a member name appears in a Windows SharePoint Services site, a user presence menu is available. The presence menu is integrated with Active Directory, Exchange, and Windows Messenger for providing information such as office location and free/busy status. It can be used for scheduling meetings and sending email.

  • Team discussions that can be expanded and collapsed.

  • If a user tries to access a resource that they don't have permission to access, Windows SharePoint Services can automatically generate a request to the owner to be given permission to access the resource. Figure 36.13 shows an example of an automatic request to the owner for permission access.

Figure 36.13. SharePoint-generated request for permission to access a resource.

[View full size image]


Customizing and Developing WSS Sites

Windows SharePoint Services has many out-of-the-box new features that make it easier to customize using the browser interface. This provides nonprogrammers with a mechanism to create and customize sites to meet their needs.

For developers, the following provides an overview of the SharePoint technical structure. Windows SharePoint Services is built on the .NET platform. Use of the .NET platform enables SharePoint to assimilate information from multiple systems into an integrated solution. ASP.NET contains many new features, and it is more responsible, secure, and scalable than ASP. Using ASP.NET reduces the amount of code that needs to be written over similar ASP solutions.

SharePoint's SQL back end provides access to internal database components using industry-standard tools. From an application standpoint, integration with BizTalk provides access to over 300 application connectors using Web Services calls.

In Windows SharePoint Services, sites and lists can be saved as templates, stored in a Site or List Template library, and then made available to all sites in the collection. There is also a library for Web Parts that can be shared across all sites in the collection.

Features such as these provide an environment for developing fully customized WSS solutions. Additional customization and development features are highlighted in the following sections.

Using the Browser to Customize SharePoint

Through the browser, you can add a logo to the team site, apply a theme, modify a list, or create a new Web Part page. In SharePoint Team Services, there was a template that contained three "zones" for placing Web Parts, producing a three-column view. In Windows SharePoint Services, there are additional zone layouts to choose from, making customization much more user friendly. The new Web Part Tool Pane is a feature that enables users to easily customize sites.

It provides the ability to

  • Drag/drop Web Parts onto a page

  • Customize Web Parts

  • Change the home page site logo

The site administrator can control what goes into the Web Part libraries and who has access to the libraries for adding Web Parts to a site. Figure 36.14 illustrates the Web Part Tool Pane with its various Web Part libraries and capability to display the contents of the library.

Figure 36.14. Displaying the Web Part Tool Pane for access to Web Part libraries.

[View full size image]

Development Enhancements for Site Templates

Windows SharePoint Services includes multiple templates that can be used when you create a new site. Each template includes a set of features from Windows SharePoint Services to satisfy a specific collaboration need. Templates are included for

  • Document collaboration

  • Team collaboration

  • Basic meetings

  • Decision meetings

  • Social meetings

  • Multiple meetings

If these don't satisfy the organization's requirements, customized templates can easily be put together using the browser-based customization features, using FrontPage or some other Web design tool, or using programming. For example, if an organization always put its company logo on the home page and used specific Web parts that were unique to their organization, it could save the site as a template and then just duplicate the template when necessary to maintain consistency and security.

Improving on FrontPage 2003 Integration

With SharePoint Team Services, it was difficult to modify SharePoint sites. FrontPage 2003 is more tightly integrated with Windows SharePoint Services and fully supports Web Parts, Web Part pages, and Web Part zones. This means that Web Parts can be added and customized using FrontPage 2003 to provide the look, feel, and content to meet organizational requirements.

Web Parts can be previewed in FrontPage before being published to the SharePoint site, thus providing an "audit" to ensure that the changes have the desired effect. The FrontPage client can be used to back up and restore Windows SharePoint Services sites, providing a much needed feature that was lacking in older versions of the product.

Other features provided in FrontPage 2003 include the ability to

  • Deploy a site throughout the organization using solution packages. This provides a means for implementing changes and modifications to organizations that have multiple sites and servers.

  • Search Web Part libraries directly from FrontPage 2003. This enables FrontPage 2003 to be a complete editing source for Web pages, as opposed to a two-step process in which the Web Parts would be added using the WSS interface, and then further modifications made in FrontPage.

  • Create list templates and create, edit, and delete SharePoint list views. For experienced FrontPage users, the SharePoint interface may be cumbersome for performing functions such as these. Therefore, FrontPage can be more efficient for these users when creating templates and managing list views.

  • Connect Web Parts across pages or on the same page to create a new user interface. Because FrontPage is a Web development tool, it has more capabilities and is more flexible than SharePoint; thus, features such as these are available for more complete customization.

  • Use a new XSL data view Web Part that can bring data from external sources into SharePoint sites. This is a great new integration feature that shows Microsoft's commitment toward a truly integrated Office solution.


Summary

Windows SharePoint Services is an excellent way to extend the capabilities of the already-capable Windows Server 2003 operating system. Installation of WSS allows a server to become an enterprise-level document management and collaboration system. Enhanced capabilities within WSS and strong integration with Microsoft Office 2003 allow organizations to realize improvements in productivity and quality quickly. In addition, the scalability of WSS and its reliability on the robust Microsoft SQL 2000 database provide strong incentive to deploy and utilize WSS technology.


Best Practices

  • Consider using a full version of SQL Server 2000/2005 for any WSS implementation with greater than 10 sites.

  • Use document versioning sparingly in WSS document libraries to ensure that the SQL database does not grow too large.

  • Keep a WSS SharePoint Server up to date with all Windows Server 2003 and SQL Server patches and updates to reduce the risk of attacks or malfunctions.

  • Deploy WSS Server(s) to replace file servers for document storage to take advantage of the newly integrated document management features WSS offers.

  • Keep the number of virtual servers created per WSS Server to 10 or fewer to avoid performance degradation.

  • Use FrontPage 2003 to provide advanced administration, site maintenance, and backup and restore capabilities.

  • Update WSS with Service Pack 2 to take advantage of the SQL 2005 support, updated patches, and advanced extranet support.

  • Use the full SharePoint Portal Server 2003 application when you need to add enterprise-level management and organization tools to WSS sites, or to consolidate information from various systems into a centralized portal.


Chapter 37. Windows Media Services

In This Chapter

  • Understanding Windows Media Services

  • Using Windows Media Services for Real-Time Live Broadcasts

  • Broadcasting Stored Single Files

  • Hosting a Directory of Videos for On-Demand Playback

  • Combining Multiple Files for a Combined Single Broadcast

  • Understanding Windows Media Encoder

  • Broadcasting a Live Event

  • Capturing Audio or Video for Future Playback

  • Using Other Windows Media Encoder Options

  • Using Microsoft Producer for Sophisticated Presentations

Years ago, content meant word processing files, spreadsheet documents, or other text-based documents. However, more recently content can include formats such as video and audio files. Unlike text-based files that are relatively small at 100KB or 250KB, audio and video files run from 35MB or even into the hundreds of megabytes in size. With the amount of storage demanded by these types of files, organizations can no longer simply place these files on file servers for users to access and save. The files need to be stored and managed by media servers, where the bandwidth demands are controlled to minimize overtaxing the bandwidth availability of the organization's network.

Microsoft provides a series of tools to help users and administrators manage video and audio content. For the server component, the Microsoft Windows Media Service that comes with Windows Server 2003 provides an organization with the capability to capture and publish video and audio content. Microsoft provides two major tools, both of which are freely downloadable, that perform media conversion (Windows Media Encoder) as well as content customization for presentations (Microsoft Producer for PowerPoint 2003).

This chapter covers both the server component of Windows Media Services, as well as the downloadable tools that provide editing and publishing support for users and administrators.


Understanding Windows Media Services

Windows Media Services is a built-in component to the Windows Server 2003 operating system. Windows Media Services enables the administrators of an organization to organize video and audio files to be published to other users. The publishing function sets the bandwidth that will be used during the file distribution, controls the number of users accessing audio and video files at the same time, and manages the overall bandwidth demands of the Windows Media Services functions.

By properly configuring and optimizing media services functions, an organization can minimize the excessive demands of media services distribution over the network. The decisions that need to be made include whether distribution will be

  • Real-time live broadcasts

  • Single broadcasts at a time

  • Multiple files combined to a single broadcast

  • Multiple files in a single directory for selective broadcasting

The various publishing options are highlighted throughout this chapter on best practices, tips, and tricks on configuring and implementing the publishing services to meet various organizational publishing needs.

System Requirements for Windows Media Services

Besides requiring a Windows Server 2003 system (Standard Edition, Enterprise Edition, or Datacenter Edition), the basic requirements for Windows Media Services are as follows:

  • 550MHz processor

  • 1GB RAM memory

  • Ethernet network adapter running TCP/IP

  • 521MB of free disk space (6MB for system files, 15MB for installation files, and 500MB minimum for content storage)

Note

Some features, such as the Multicast Content Delivery functionality, require the Windows Media Services to be installed on a Windows Server 2003 Enterprise Edition or Datacenter Edition to operate.

The key to the Windows Media Services system is having enough processing speed to handle the media streaming requests, enough RAM to cache the media streams, and enough disk space to store the video files being shared and published.

Tip

To improve the performance of a Windows Media Services system, placing the operating system and program files on one drive and placing the video files on another drive set will distribute the normal server processes from the read/write access of the video files. Additionally, placing striped drive sets with ample hard drive controller cache can improve both the sequential and parallel read/write requests of the video files.

Testing the Load on a Windows Media Server

For organizations that want to test the performance load of actual video read/write requests to a Windows Media Server, Microsoft provides a load simulation tool called the Windows Media Load Simulator for Windows Media Services 9 Series. This tool can be downloaded free from the Microsoft Web site at http://www.microsoft.com/windows/windowsmedia/9series/server/loadsim.aspx.

After downloading the load simulation tool, you can install it by running the wmloadsetup.exe program. You will be prompted to agree to the licensing of the tool. After you click Yes, the tool installs. After installation, you will be asked if you would like to start the load simulation program. If you click Yes, the simulator will begin. If you choose to launch the simulator at a later date, the program can be accessed by choosing Start, Programs, Windows Media Load Simulator, and then selecting the Windows Media Load Simulator application icon.

Once in the Load Simulator screen, click Properties to enter the selected options to test video load on a Windows Media server. The settings for the property configuration should be similar to the ones shown in Figure 37.1. After the properties have been selected, click the Start Test button to begin the simulation process.

Figure 37.1. Properties page for the load simulator tool.

[View full size image]

Note

Although the simulation program is called a load simulator, the reading and writing of information is actually being transacted against a live Windows Media server. Unlike some load simulators that simulate even a server operation, the Windows Media Load Simulator for Windows Media Services 9 Series is actually running against a fully operational server. This provides real-world transactions to test hardware, software, and LAN/WAN traffic patterns for testing purposes.

Installing Windows Media Services

Because Windows Media Services comes as part of the Windows Server 2003 operating system, the installation process is merely adding in the Windows Media Services component. To install the component on an existing Windows Server 2003 system, do the following:

1. | Click Start, Settings, Control Panel and then double-click Add/Remove Programs.
2. | Click the Add/Remove Windows Components option and then scroll down to the Windows Media Services section and select the check box for the desired option. Click Next to continue installing components, and then click Finished when done.

Configuring the Windows Media Services

Once installed, the services for Windows Media Services are set to run automatically. The next step is to configure Windows Media Services to meet the video and audio publishing requirements of the organization. To do so, launch the Windows Media Services MMC administration tool by selecting Start, Programs, Administrative Tools, Windows Media Services. You will see a screen similar to the one in Figure 37.2.

Figure 37.2. The Windows Media Services MMC administration tool.

[View full size image]


Using Windows Media Services for Real-Time Live Broadcasts

A Windows Media Services server can be used as the host to broadcast real-time videos. With a camera attached to the broadcasting server, video can be captured and published to multiple users. Real-time live broadcast videos are commonly used for organizational press releases or announcements, distributed broadcasting of conference sessions or training classes, or video-published company meetings.

Configuring a Server for Real-Time Live Broadcasts

To configure a Windows Media Server for real-time live broadcasts, a publishing point needs to be configured for live communications. The configuration process is as follows:

1.
In the Windows Media Services MMC, right-click on Publishing Points in the navigation tree and select Add Publishing Point (Wizard).

2.
Click Next to move past the Welcome screen.

3.
Enter a publishing point name that describes the function. In the case of this live broadcast, you might choose something like Live Company Mtg 7-12-04. Click Next to continue.

Note

The name of a publishing point should not have special characters such as <, >, \, ?, %, &, ', #, ", {, }, [, ], or *. These characters can interfere with the successful publishing of the broadcast over the Internet.

4.
Select Encoder (A Live Stream) and click Next.

5.
Select Broadcast Publishing Point and click Next.

6.
Select Unicast or Multicast as the delivery option for the broadcasting publishing point and then click Next.

Unicast versus Multicast

The Unicast delivery option sets up a one-to-one video stream between the Windows Media Server and each client system, whereas the Multicast delivery option sends a single video stream that can be accessed by multiple users simultaneously.

The Unicast delivery method is simpler to configure and more likely to work without much network infrastructure (router, firewall, system configuration) changes. However, Unicast is a significantly more bandwidth-intensive environment. Because each client-to-server session is a separate video stream, a broadcast with 10 users would have 10 video streams from the server to the clients, and a broadcast with 100 users would feature 100 video streams from the server to the clients. For a relatively small or low-demand Windows Media Server environment, Unicast delivery is easier to implement, but be careful when using Unicast delivery in large or broadly distributed environments.

The Multicast delivery method sends a single video stream out on the network, which can be accessed by multiple client systems simultaneously. With a Multicast delivery stream, whether 10 users or 100 users need to access the system, there is only a single broadcast either way. However, for a Multicast delivery to work, the routers must be configured to support Multicast routing. The client systems receiving the Multicast broadcasts need to be running Windows 2000, Windows XP Professional, Windows 2000, or Windows 2003 Server.

An additional consideration for choosing between the Unicast and Multicast delivery methods is the number of clients that expect to connect to the broadcast stream and the variation of client configurations. If the compatibility to accept broadcasts from various systems is important and the number of connections to a broadcast stream is limited, the Unicast method will provide better compatibility. If the organization controls the desktop configurations and knows the client systems can accept Multicast broadcasts and the organization is broadcasting a video to be received by many users, the Multicast delivery method will lessen the demand on network bandwidth.

7.
Enter the URL for the encoder. This is typically the name of the Windows Media Server, such as http://server or http://media.companyabc.com, depending on whether the server has been added to DNS for naming. Click Next to continue.

8.
Select the Enable Logging option if you want to log media events and then click Next.

9.
The next screen shows a summary of the created publishing point, similar to the one shown in Figure 37.3. You can choose to start the publishing point when the wizard is finished, and if you want to capture and archive the live event, select the Start Archiving When Publishing Point Starts option. Click Next.

Figure 37.3. Summary of the created publishing point.

10.
Before finishing with the Publishing Wizard, you are prompted to choose between three file creation options:

  • Create an Announcement File (.asx) or Web Page (.htm) An announcement file is similar to an invitation file that can be used to notify users of a pending live broadcast or the availability of an on-demand video playback session.

  • Create a Wrapper Playlist (.wsx) A wrapper playlist is content that can be added to either the start or end of a broadcast. An example of wrapper content might be a welcome or closing message, advertisements, or broadcast identification.

  • Create a Wrapper Playlist (.wsx) and Announcement File (.asx) or Web Page (.htm) Choosing this option launches both the Announcement File and Wrapper Playlist Wizards to create the invitation announcement, as well as the capability to add content at the start or end of a broadcast.

Choose one of these three options or deselect the After the Wizard Finishes box if you don't want to choose any of the options. Click Finished when complete.

Starting a Real-Time Live Broadcast

A live broadcast can be started immediately or at a later time. Many organizations create the live broadcast publishing point and test the session to ensure that the session process is working properly. Some key aspects to test include making sure the camera and lighting are acceptable for view, and ensuring that the microphone is working and the audio quality and volume are acceptable.

After the live broadcast is tested, the session can be stopped and started at the time of the live broadcast. To start a broadcast, right-click on the publishing point and select Start, as shown in Figure 37.4. When the broadcast is complete, clicking the Stop button stops the broadcast session.

Figure 37.4. Starting a publishing point.

[View full size image]


Broadcasting Stored Single Files

A Windows Media Services system can be set up to host the broadcasting of a single video file. A single video file broadcast is typically set up on-demand, meaning that a user requests the playback of the video file on request. On-demand video playbacks are commonly used for replays of video files such as on-demand training classes, or viewing captured meetings or presentations.

Configuring a Server for Single On-Demand Video Playback

To configure a Windows Media Server for on-demand video playback broadcasts, a publishing point needs to be configured for on-demand communications. The configuration process is as follows:

1.
In the Windows Media Services MMC, right-click on Publishing Points in the navigation tree and select Add Publishing Point (Wizard).

2.
Click Next to move past the Welcome screen.

3.
Enter a publishing point name that describes the function. In the case of this on-demand single file broadcast, you might choose something like Company Mtg 6-9-04. Click Next to continue.

Note

The name of a publishing point should not have special characters such as <, >, \, ?, %, &, ', #, ", {, }, [, ], or *. These characters can interfere with the successful publishing of the broadcast over the Internet.

4.
Select One File (Useful for a Broadcast of an Archived File) and click Next.

5.
Choose either Broadcast Publishing Point or On-Demand Publishing Point and click Next.

Broadcast Publishing versus On-Demand Publishing

Broadcast publishing is a process where the publishing of a video is scheduled, similar to a television program. A time is scheduled when the stored video file will be played back. This might be used in an environment in which training videos are played back during specific times during the day for employees to view.

On-demand publishing is a process where an individual requests the playback of a video file. This allows users the flexibility of deciding when they watch a video.

As each session is independent with on-demand video, there is no benefit to doing a Multicast session because the video will only be viewed by an individual. Therefore, the default delivery option for on-demand published videos is Unicast, and the Multicast option is not provided.

When choosing a broadcast published video, because multiple users are likely to access the broadcast at the same time, the organization can choose to Multicast the video as long as the remote client systems and network infrastructure support Multicast video routing. With Multicast delivery, the Enable Unicast Rollover option provides a Unicast delivery stream if the remote client does not support Multicast broadcasts.

At this point, whether you selected Broadcast Publishing Point or On-Demand Publishing Point in step 5 will determine what options are available in the remaining steps of the wizard.

If you selected On-Demand Publishing Point in step 5, you will be prompted to either add a new publishing point (which will start the wizard over back at step 2), or you can select Use an Existing Publishing Point and then click Next to finish the on-demand file publishing point.

If you selected Broadcast Publishing Point in step 5, you will be prompted with several other options.

1.
Select Unicast or Multicast as the delivery option for the broadcasting publishing point and then click Next.

2.
You will then be prompted for the name of the file that you want to publish. Select the file and then click Next.

3.
Select the Enable Logging option if you want to log media events and then click Next.

4.
The next screen shows a summary of the created publishing point. You can choose to start the publishing point when the wizard is finished, and if you want to capture and archive the live event, select the Start Archiving When Publishing Point Starts option. Click Next to continue.

5.
Before finishing the Publishing Wizard, you are prompted to choose between three file creation options:

  • Create an Announcement File (.asx) or Web Page (.htm) An announcement file is similar to an invitation file that can be used to notify users of a pending live broadcast or the availability of an on-demand video playback session.

  • Create a Wrapper Playlist (.wsx) A wrapper playlist is content that can be added to either the start or end of a broadcast. An example of wrapper content might be a welcome or closing message, advertisements, or broadcast identification.

  • Create a Wrapper Playlist (.wsx) and Announcement File (.asx) or Web Page (.htm) Choosing this option launches both the Announcement File and Wrapper Playlist Wizards to create the invitation announcement, as well as the capability to add content at the start or end of a broadcast.

Choose one of these three options or deselect the After the Wizard Finishes box if you don't want to choose any of the options. Click Finished when complete.

Starting a Single File Publishing Point

A single file publishing point can be started immediately or at a later time. Unless the broadcast is to be scheduled at a different time, usually single file publishing points are started immediately so that they can be accessed at any time. Testing a file publishing point ensures that the session process is working properly. Some key aspects to test include making sure the Multicast delivery broadcasting is working properly, and that the video and audio quality and volume are acceptable.


Hosting a Directory of Videos for On-Demand Playback

If the organization wants to publish an entire directory of files, the Windows Media Server can be configured to publish a number of video files. The hosting of a directory of videos is typically set up on an on-demand basis to provide users with access to a number of videos. Whereas the single file broadcast has a single file associated to a publishing point, the hosting of a directory eliminates the need to selectively publish each file. Instead, the directory is published and files can simply be copied to the directory, where users can then request them.

Configuring a Server to Host a Directory of Videos for Playback

To configure a Windows Media Server for on-demand video playback of any file in a directory on the server, a publishing point needs to be configured for publishing a directory of files. The configuration process is as follows:

1. | In the Windows Media Services MMC, right-click on Publishing Points in the navigation tree and select Add Publishing Point (Wizard).
2. | Click Next to move past the Welcome screen.
3. | Enter a publishing point name that describes the function. When broadcasting a directory of files, you might choose something like Company Training Files. Click Next to continue. Note The name of a publishing point should not have special characters such as <, >, \, ?, %, &, ', #, ", {, }, [, ], or *. These characters can interfere with the successful publishing of the broadcast over the Internet.
4. | Select the Files (Digital Media Playlists) in a Directory (Useful for Providing Access for On-Demand Playback Through a Single Publishing Point) option and click Next.
5. | Choose either Broadcast Publishing Point or On-Demand Publishing Point. Refer to the "Broadcast Publishing Versus On-Demand Publishing" sidebar for decisions on publishing points. Click Next to continue.

At this point, whether you selected Broadcast Publishing Point or On-Demand Publishing Point in step 5 will determine what options are available in the remaining steps of the wizard.

If you selected On-Demand Publishing Point in step 5, you will be prompted with a series of questions:

1.
You will be prompted to add the name of the directory where the published files will be stored. You can also choose to allow access to the subdirectory using wildcards. Click Next to continue.

2.
A choice to select content playback gives you the option to loop videos, shuffle videos, both, or none. Make your choices and click Next to continue.

Loop, Shuffle, Both, or None

Looping videos means that when the video is complete, it will start from the beginning and play again. This is a good option for kiosks or other public systems where a video will be played over and over.

Shuffle means that the video being played will be randomly selected from any one of the videos in the directory. This option provides an organization with the choice of selecting the streaming files it wants to display. This might be a good option for advertisements or for public kiosk systems. However, the shuffle process only randomly plays the videos in the directory once. The videos will stop after all the files have been played back.

If both looping and shuffle are selected, the videos in the directory will be played randomly, and the publishing of videos will be continuous. This is the best option for organizations that want different videos displayed continuously.

You can also choose neither of these options. This is the best option for the publishing and on-demand playback of any of the videos in the directory. The videos are selected individually and they play once. Upon completion, the video stops and allows the user to choose another video to play back.

3.
Select the Enable Logging option if you want to log media events and then click Next.

4.
The next screen shows a summary of the created publishing point. You can choose to start the publishing point when the wizard is finished, and if you want to capture and archive the live event, select the Start Archiving When Publishing Point Starts option. Click Next to continue.

If you selected Broadcast Publishing Point in step 5, you will be prompted with several other options:

1.
Select Unicast or Multicast as the delivery option for the broadcasting publishing point and then click Next.

2.
You will then be prompted for the name of the directory that you want to publish. Select the directory and then click Next.

3.
A choice to select content playback gives you the option to loop videos, shuffle videos, both, or none. Make your choices and click Next to continue.

4.
Select the Enable Logging option if you want to log media events and then click Next.

5.
The next screen shows a summary of the created publishing point, as shown in Figure 37.5. You can choose to start the publishing point when the wizard is finished, and if you want to capture and archive the live event, select the Start Archiving When Publishing Point Starts option. Click Next to continue.

Figure 37.5. Viewing the summary of a directory publishing point.

For either the broadcast or on-demand publishing options, before finishing the Publishing Wizard, you are prompted to choose between three file creation options:

  • Create an Announcement File (.asx) or Web Page (.htm) An announcement file is similar to an invitation file that can be used to notify users of a pending live broadcast or the availability of an on-demand video playback session.

  • Create a Wrapper Playlist (.wsx) A wrapper playlist is content that can be added to either the start or end of a broadcast. An example of wrapper content might be a welcome or closing message, advertisements, or broadcast identification.

  • Create a Wrapper Playlist (.wsx) and Announcement File (.asx) or Web Page (.htm) Choosing this option launches both the Announcement File and Wrapper Playlist Wizards to create the invitation announcement, as well as the capability to add content at the start or end of a broadcast.

Choose one of these three options or deselect the After the Wizard Finishes box if you don't want to choose any of the options. Click Finished when complete.

Starting a File from Within the Directory Publishing Point

A single file can be viewed from within the directory publishing point. Depending on the option selected, a user simply enters the URL of the directory publishing point (such as mms://media.companyabc.com/pubpoint/) followed by the name of the individual file in the directory (like TRaining-Jan-21st.wmv). The full URL would be mms://media. companyabc.com/pubpoint/training-jan-21.wmv. The advantage of the directory publishing point is that a media administrator can simply copy more files to the directory and the initial publishing point directory URL remains the sameonly the filename changes for each file being accessed. A single publishing point can also be created without the need of individually publishing files one by one.


Combining Multiple Files for a Combined Single Broadcast

There are times when a broadcast administrator wants to combine several media files but only has the ability to publish just one video stream. The individual media files are added to a playlist, and the playlist is then published so that a single publishing point will play back the entire playlist of files. The playlist concept is frequently used for audio files where a playlist of music files are combined, yet only a single stream is distributed. Or the playlist file may be constantly updated to include new media files that are needed for publishing and distribution. The benefit of creating a playlist and combining the content into a single broadcast is the ability to have just a single broadcast point that brings to users multiple files.

Configuring a Server for Playlist Broadcasting of Multiple Files

To configure a Windows Media Server for broadcasting multiple files into a single stream, a publishing point needs to be configured for playlist broadcasting. The configuration process is as follows:

1. | In the Windows Media Services MMC, right-click on Publishing Points in the navigation tree and select Add Publishing Point (Wizard).
2. | Click Next to move past the Welcome screen.
3. | Enter a publishing point name that describes the function. When playlist broadcasting of multiple files, you might choose something like Playlist of Conf Content. Click Next to continue. Note The name of a publishing point should not have special characters such as <, >, \, ?, %, &, ', #, ", {, }, [, ], or *. These characters can interfere with the successful publishing of the broadcast over the Internet.
4. | Select the Playlist (a Mix of Files and/or Live Streams That You Combine into a Continuous Stream) option and click Next.
5. | Choose either Broadcast Publishing Point or On-Demand Publishing Point. Refer to the "Broadcast Publishing Versus On-Demand Publishing" sidebar for decisions on publishing points. Click Next.

At this point, whether you selected Broadcast Publishing Point or On-Demand Publishing Point in step 5 will determine what options are available in the remaining steps of the wizard.

If you selected On-Demand Publishing Point in step 5, you will be prompted with a series of questions:

1.
You will be prompted whether you want to add a new publishing point (or playlist), which you will typically want to do. Select Add a New Publishing Point and click Next.

2.
You will be prompted to add the name of a playlist where the published files will be listed and stored. Enter the name of an existing playlist, or select the Create a New Playlist option. Click Next to continue.

3.
If you choose to create a new playlist, you will be prompted to add media and add advertisements into your playlist file, as shown in Figure 37.6. Click Next.

Figure 37.6. Choosing media to add to the playlist.

[View full size image]

4.
Enter a name of your playlist and then click Next.

5.
A choice to select content playback gives you the option to loop videos, shuffle videos, both, or none. For more information on these options, see the "Loop, Shuffle, Both, or None" sidebar earlier in this chapter. Click Next to continue.

6.
Select the Enable Logging option if you want to log media events and then click Next.

7.
The next screen shows a summary of the created publishing point. You can choose to start the publishing point when the wizard is finished, and if you want to capture and archive the live event, select the Start Archiving When Publishing Point Starts option. Click Next to continue.

If you selected the Broadcast Publishing Point option earlier in this sequence, you will be prompted with several other options:

1. | Select Unicast or Multicast as the delivery option for the broadcasting publishing point and then click Next.
2. | If you choose to create a new playlist, you will be prompted to add media and add advertisements into your playlist file. Click Next.
3. | Enter a name of your playlist and then click Next.
4. | A choice to select content playback gives you the option to loop videos, shuffle videos, both, or none. For more information on these options, see the "Loop, Shuffle, Both, or None" sidebar earlier in this chapter. Click Next to continue.
5. | Select the Enable Logging option if you want to log media events and then click Next.
6. | The next screen shows a summary of the created publishing point. You can choose to start the publishing point when the wizard is finished, and if you want to capture and archive the live event, select the Start Archiving When Publishing Point Starts option. Click Next to continue.

For either the broadcast or on-demand publishing options, before finishing the Publishing Wizard, you are prompted to choose between three file creation options:

  • Create an Announcement File (.asx) or Web Page (.htm) An announcement file is similar to an invitation file that can be used to notify users of a pending live broadcast or the availability of an on-demand video playback session.

  • Create a Wrapper Playlist (.wsx) A wrapper playlist is content that can be added to either the start or end of a broadcast. An example of wrapper content might be a welcome or closing message, advertisements, or broadcast identification.

  • Create a Wrapper Playlist (.wsx) and Announcement File (.asx) or Web Page (.htm) Choosing this option launches both the Announcement File and Wrapper Playlist Wizards to create the invitation announcement, as well as the capability to add content at the start or end of a broadcast.

Choose one of these three options or deselect the After the Wizard Finishes box if you don't want to choose any of the options. Click Finished when complete.

Starting a Playlist from Within the Playlist Publishing Point

A playlist can be launched to initiate the playback of media contained within the playlist file. Depending on the option selected, a user simply enters the URL of the directory publishing point (such as mms://media.companyabc.com/Corp Playlist). The playlist of files will begin to publish the first of the media clips and will continue through the entire playlist until the list is complete. If the loop option was selected in the publishing point configuration settings, the playlist will continuously loop the media content of the playlist. If shuffle was selected, the files within the playlist will be played randomly.

Any of the options selected from within the configuration setting can be modified at any time to change or reconfigure settings initially created in the wizard installation process.


Understanding Windows Media Encoder

For any media content producer that is working with audio and video content, the Microsoft free Windows Media Encoder is a must-have tool for capturing and converting media content. Although the Windows Media Server can be used to capture and publish video files, it's unlikely that a content producer will want to travel around with a Media Server everywhere. Instead, by downloading the Windows Media Encoder and installing it on any Windows 2000 or XP laptop or workstation, the producer can travel with the mobile system instead of a server.

Note

The Windows Media Encoder can be downloaded at http://www.microsoft.com/downloads/details.aspx?FamilyID=5691ba02-e496-465a-bba9-b2f1182cdf24&DisplayLang=en.

Additionally, the Windows Media Encoder provides tools to convert files from one video format to another, such as from AVI format to MPG format. One of the biggest limitations of the Windows Media Encoder is its inability to perform simple edits to the media files. For this, you need to download and use third-party tools.

Editing Tools

Because Microsoft does not provide freely downloadable video-editing tools, content producers need to look for other tools to perform basic cropping at the start or end of a video file, or when merging video files. There are dozens of professional video editing and content production programs available, such as Adobe's Premiere Pro or Ulead's VideoStudio. There are also hundreds of third-party shareware and freeware tools that can be downloaded from the Internet for little or no money.

When looking at video-cropping tools that can cut content from the start or end of a file or split video files into multiple files, it's important to look at whether the utility rewrites the original file into a new video format, or whether it merely crops portions of the file and retains the original video format for the remainder of the file. One such tool that provides very simple and low-cost video cropping and splitting functionality is BoilSoft's AVI/MPEG/ASF/WMV Splitter. For less than about U.S. $35, the tool crops files while retaining the existing file format and structure of the original file. See http://www.boilsoft.com for more information.

BoilSoft also offers an AVI/MPEG/RM/WMV Joiner utility for labout U.S. $25 that will combine multiple files into a larger file. This is helpful when multiple small files need to be combined to create a single streaming video session.

The biggest challenge video producers face is selecting a utility that meets all their needs. Most downloadable tools offer trial versions with trial periods that allow you to try the software before buying it. If you don't find the tool you're looking for at first, jump back on the Internet and keep searching. Tools f]or every video and audio editing need seem to be readily available.

Understanding the Requirements for the Windows Media Encoder

The Windows Media Encoder runs on Windows 2000 and Windows XP desktops, as well as on Windows 2000 and Windows 2003 servers. The basic configuration of the system depends on the task being performed by the Windows Media Encoder software. Microsoft recommends the system configurations shown in Table 37.1.

Table 37.1. Requirements for Windows Media Encoder

Encoding Task

Requirement

Recommendation

Conversion of files

266MHz processor, such as an Intel Pentium with MMX

500MHz processor, such as an Intel Pentium III or AMD Athlon

64MB of available memory

128MB of available memory

Capture and broadcast of audio files

266MHz processor, such as an Intel Pentium with MMX

866MHz processor, such as an Intel Pentium III or AMD Athlon

64MB of available memory

128MB of available memory

Supported video/audio capture device

Supported video/audio capture device

Capture and broadcast of audio and video files for dial-up modem and mid-width audiences using Windows Media Audio 9 and Windows Media Video 7 codecs

300MHz processor, such as an Intel Pentium III or AMD Athlon 64MB of available memory
Supported video/audio capture device

28.8KB or 56KB modem

866MHz processor such as an Intel Pentium III or AMD Athlon
256MB of available memoryband Supported video/audio capture device

100KB500KB data connection

Capture and broadcast of audio and video files for dial-up modem and mid-bandwidth audiences using Windows Media Audio and Video 9 codecs

1.5GHz processor, such as an Intel Pentium 4 or AMD Athlon XP 1800
64MB of available memory
Supported video/audio capture device
28.8KB or 56KB modem

Dual 1GHz processor, such as an Intel Pentium III or Xeon or AMD Athlon MP
256MB of available memory Supported video/audio capture device
100KB500KB data connection

Capture and broadcast of audio and video files for high-bandwidth audiences using Windows Media Audio and Video 9 codecs

1.5GHz processor, such as an Intel Pentium 4 or AMD Athlon XP 1800
64MB of available memory
Supported video/audio capture device
500KB and faster data connection

Dual 2GHz processor, such as an Intel Xeon or AMD Athlon MP
256MB of available memory
Supported video/audio capture device
500KB and faster data connection

As with most video processing applications, there is high demand for memory, processing speed, and disk space. The faster the system, the faster the capture and processing of information. If the system is not fast enough, in many cases frames are dropped, thus causing jitter or skips in the video being processed. It is recommended that you test the performance of a system to ensure that it meets the quality requirements of the organization.

Installing the Windows Media Encoder

After downloading the Windows Media Encoder from the Microsoft Web site, the software can be installed on any system meeting the requirements noted in Table 37.1. The installation process is as follows:

1. | Run the WMENCODER.EXE file to begin the installation process.
2. | Click Next to move past the Welcome screen.
3. | After accepting the licensing agreement, click the I Accept the Terms of the License Agreement option and click Next.
4. | Select a custom installation folder or just click Next to choose the default folder. Then click Install to begin the installation.
5. | Click Finish when prompted.

Once installed, the Windows Media Encoder can be launched by selecting Start, Programs, Windows Media, Windows Media Encoder. Upon launching the Windows Media Encoder, you will see a New Session screen similar to the one shown in Figure 37.7.

Figure 37.7. Windows Media Encoder new session options.

[View full size image]


Broadcasting a Live Event

The Windows Media Encoder can be used in conjunction with a Windows Media Server to broadcast a live event. This gives an organization the capability to use the Windows Media Server as the back-end server to publish the live content to multiple users. Also, a laptop or some other mobile or portable device can then act as the system capturing the video/audio content that will be published by the Windows Media Server.

Preparing for a Live Broadcast

To prepare for a live broadcast, a Windows 2000/Windows XP workstation, a Windows 2000/Windows 2003 server with compatible camera and microphone, or a system with a video/audio capture card must be configured and tested for basic functionality. The camera and audio devices should be able to capture and record video and audio content at the desired level of quality. Once the remote system is working properly, the live broadcast can be initiated.

Initiating a Live Broadcast

To start a live broadcast, Windows Media Encoder should be launched on the broadcasting system. Once launched, follow these steps:

1. | Select Broadcast a New Event and then click OK.
2. | Select the video and audio device source that will be capturing the event. Click Next when ready. Note For systems with only a single video and audio source, the options should default to the only devices in the system. However, for systems with an audio and video capture card installed, the onboard audio might also be an option, so be certain that the right video and audio devices are selected. When choosing the audio device, you might want to click Configure and confirm that the microphone has been enabled. Many systems automatically have the microphone disabled, so although the correct device has been selected, no sound will be captured.
3. | The next setting allows the Windows Media Encoder system to either push the video/audio stream to a Windows Media Server on the network, or allows the Windows Media Server to initiate a pull from the encoder system. Make the choice and then click Next to continue.

Note

The choice of whether to push or pull media content depends on what you are closer to. If you are closest to the Windows Media Encoder system (you are in the room where the event is taking place), you'd probably want to push the video/audio stream to the Windows Media Server. A push from the encoder system causes the Windows Media Server to automatically start publishing the session.

If the Windows Media Encoder system is set up in a room and you are with the server, but not necessarily where the encoder system is located, you can initiate the capture remotely by choosing to have the Windows Media Server initiate the session.

If you choose to push to the Windows Media Server, you will be prompted with the following steps:

1.
You will be prompted to enter the name of the Windows Media Server and the publishing point, and you have the option of copying the publishing point settings from another configuration. When completely filled out, the form looks similar to Figure 37.8. Click Next when ready.

Figure 37.8. Pushing a live broadcast to a media server.

2.
The next screen will prompt for the encoding options. The various bit rate for encoding will be shown, displaying Total Bit Rate, Frame Rate, and Output Size. Choose the desired bit rate or bit rates and then click Next to continue.

Choosing the Bit Rate(s)

When given the option of choosing the bit rate or bit rates supported, keep in mind the quality desired as well as the bandwidth available to publish the media files.

If users are dialing in to receive the published content, you do not want a total bit rate that exceeds the available bandwidth of the dial-up modem session. Just because a user has a 56KB modem does not mean that user is getting a 56KB bit-rate speed. A bit rate lower than the available bandwidth should be chosen.

Multiple bit rates can be selected for the encoding options so that a modem rate (possibly 24Kbps or 37Kbps), a DSL/cable modem rate (possibly 135Kbps or 240Kbps), or high quality rate (possibly 500Kbps or greater) can be selected. With multiple bit rates, the bit rate that meets the transmission speed of the remote client system will be used. Therefore, a user coming in over DSL might get a 135Kbps transmission, and a user coming in over a dial-up modem might get the same transmission at 24Kbps.

When selecting multiple bit rates, one thing to consider is the size of the captured file. The more bit rates that are selected, the larger the file will be. Each bit-rate encoding option selected will capture a video and audio stream for that mode. So if 12 bit-rate encoding options are selected, 12 streams of the content will be stored in the file.

Another point to consider is the desired available bandwidth. Even if all the users have high-speed network connections and can accept a 768Kbps bit-rate encoded stream, if the file is published using Unicast broadcasting, a network might become oversaturated with too much data. A lower captured video stream can allow more users access to the information.

3.
For live broadcasts, an archive copy of the broadcast file can be captured and saved to disk. This allows for future playback of the session. Select the check box to archive the file and enter a filename to capture the session. Click Next to continue.

4.
Information can be added to the broadcast file, such as title, author, copyright information, rating, and description. This information is optional. Enter the desired information and click Next to continue.

5.
The next screen gives you the option to begin the broadcast when the Finish button is clicked, or to simply finish the configuration and start the session later. Make the appropriate selection and click Finish.

If you choose to pull where the session is initiated by the Windows Media Server from the encoder, you will be prompted with the following steps:

1. | You will be prompted to enter a free HTTP port that can be used to communicate between the Windows Media Server and the Windows Media Encoder system. Port 8080 is the default, but by clicking the Find Free Port button, you can search for an open port. Click Next to continue.
2. | The next screen prompts you for the encoding options. The various bit rate for encoding will be shown, displaying Total Bit Rate, Frame Rate, and Output Size. Choose the desired bit rate or bit rates. Refer to the "Choosing the Bit Rate(s)" sidebar for more details. Click Next to continue.
3. | For live broadcasts, an archive copy of the broadcast file can be captured and saved to disk. This allows for future playback of the session. Select the check box to archive the file and enter a filename to capture the session. Click Next to continue.
4. | Information can be added to the broadcast file, such as title, author, copyright information, rating, and description. This information is optional. Enter the desired information and click Next to continue.
5. | The next screen gives you the option to begin the broadcast when the Finish button is clicked, or to simply finish the configuration and start the session later. Make the appropriate selection and click Finish.

For live broadcasts, it's usually preferable to test the broadcast process to make sure that the lighting, sound quality, and video quality are at the desired level. Playing around with the different bit rates can provide better results based on the needs of the organization. Although a producer may choose a higher bit rate to get better quality, the results might not be better than those obtained at a lower bit rate and with presumably lower-quality published media. If the lower bit rate produces results that are still acceptable, lowering the bit rate can minimize bandwidth demands on the network, creating less demand on the network and allowing the organization to have more simultaneous media streams.


Capturing Audio or Video for Future Playback

If you want to capture a session but there is no need for an immediate live broadcast, choosing the Capture Audio or Video option enables the Windows Media Encoder to capture and encode the session for future playback. This option can be used to capture training or conference sessions, press releases that will be broadcast at a later time and date, or organizational activities such as parties. The captured content can be stored and played back either on a scheduled broadcast basis or on demand.

Preparing for a Captured Session

To prepare for a captured broadcast, a Windows 2000/Windows XP workstation, a Windows 2000/Windows 2003 server with compatible camera and microphone, or a system with a video/audio capture card must be configured and tested for basic functionality. The camera and audio devices should be able to capture and record video and audio content at the desired level of quality. Once the remote system is working properly, a session can be captured.

Capturing a Session for Future Broadcast

To capture a session, Windows Media Encoder should be launched on a system that has a camera, microphone, and enough disk space to capture the content. Once launched, follow these steps:

1.
Select Capture Audio or Video and then click OK.

2.
Select the video and audio device source that will be capturing the event. Refer to the "Choosing the Bit Rate(s)" sidebar for more details on choosing the capture options. Click Next.

3.
Enter a name for the file to be saved. Click Next to continue.

Note

Don't worry about adding an extension to the filename. A .wmv file extension will be initially created for video files (Windows Media Video), and a .wma file extension will be initially created for audio files (Windows Media Audio).

4.
Choose how you want to distribute your content. Your choices are Windows Media Server (Streaming), Web Server (Progressive Download), Windows Media Hardware Profiles, PocketPC, or File Archive. Click Next to continue.

Choosing the Distribution Content Method

When given the option of choosing the content distribution method, the various options determine the options given on the next screen of the wizard.

When the Windows Media Server (Streaming) option is selected, the capture of the media will have multiple bit-rate options because Windows Media Servers support variable bit rates, and multiple users can receive a different media stream based on their connection bandwidth.

When the Web Server (Progressive Download) option is selected, a recommended option is selected because Web servers only support a single bit-rate distribution. Typically, the Web server option chooses a lower bit-rate option to take the variable bandwidth capabilities of Web users into consideration.

The Windows Media Hardware Profiles option provides the option of choosing a single video and audio bit rate at a higher bit rate than the Web server option. When a Windows Media hardware profile has been defined on the system, a specific bandwidth and quality can be generated.

PocketPC devices typically have limited cache, buffer, and storage space, so a lower bit-rate option is recommended. This becomes the lowest common denominator for media capture and playback.

Lastly, the File Archive option creates the smallest captured file. However, the quality of the video is typically poor, although the audio is of good quality. The assumption on this setting is that the audio information is more important than the video information.

Choosing the right method of recording produces better results for the system playing back the content.

5.
Optional information can be added to the captured file, such as title, author, copyright, rating, and description information. Enter the desired information and click Next to continue.

6.
The next screen gives you the option to begin the capture when the Finish button is clicked, or to simply finish the configuration and start the session later. Make the appropriate selection and click Finish.

Because a live session is not being viewed, sometimes it's hard to know what the resulting quality of the captured video and audio will be. Testing the various capture methods and fiddling with the bit rates can confirm whether the resulting video and distribution of the video content will be acceptable.


Using Other Windows Media Encoder Options

The Windows Media Encoder can also convert videos as well as capture screen content from a video session. These functions are useful utility features that give media producers some basic tools for editing and publishing content.

Capturing Screen Content with the Windows Media Encoder Software

Capturing screen content from video is not as simple as you might think. Simply pressing Ctrl+Print Screen does not capture video content. This usually results in a grayed-out box where the video was being played. Third-party screen capture tools also typically do not capture video screensthey typically capture bit images of a video screen, and the DirectX video or streaming video caches video content that does not show up on the active screen.

A tool like the one built in to the Windows Media Encoder allows users to capture video screens. The screen capture function in the Windows Media Encoder can capture an entire streaming video session. This is useful if you are watching a Webcast, a video stream, or some other session that you might not otherwise be able to download for replay later. By capturing the entire video and audio session using the Windows Media Encoder, you can bypass any access limitations to the streaming information.

To capture a screen using the Windows Media Encoder, do the following:

1. | Click the Capture a Screen option and then click OK.
2. | On the Screen Capture Session window, choose to capture a specific window, a region of the screen, or the entire screen. Choose to capture audio from the default audio device by selecting the appropriate check box and then click Next.
3. | Depending on the option selected in step 2, choose the window or region you want to capture and then click Next.
4. | Enter the name of the file to which you want to capture the file and then click Next.
5. | Choose the quality setting: low, medium, or high. Click Next to continue.
6. | Optional information can be added to the captured file, such as title, author, copyright information, rating, and description. Enter the desired information and click Next to continue.
7. | The next screen gives you the option to begin the capture when the Finish button is clicked, or to simply finish the configuration and start the session later. Make the appropriate selection and click Finish.

After the session has been captured, it can be played back by opening the file with Windows Media Player or another video playback tool.

Converting Videos to Windows Media Video Format

Converting a file might be necessary for the producer of media content. Many times, a video file is stored in a format or has been encoded with a codec that is not widely or easily distributed. A video file might also be stored in a format that does not support the Windows Media Server publishing capabilities. One way to convert the file is to use the screen-capturing capability of Windows Media Encoder as covered in the section "Capturing Screen Content with the Windows Media Encoder Software." The other way to convert the video is to use the conversion functionality built in to the Windows Media Encoder.

The Windows Media Encoder can convert files from the ASF, AVI, BMP, JPG, MPG, MP3, WAV, WMA, and WMV formats to a WMV video format supported by the Windows Media Server. To initiate a file conversion, do the following:

1. | Click the Convert a File option in the Windows Media Encoder software and then click OK.
2. | Select the source file of the file you want to convert. Choose the directory and filename where you want the output written. Click Next to continue.
3. | Choose how you want to distribute your content. Your choices are File Download, Hardware Devices (CD, DVD, Portable), Windows Media Server (Streaming), Web Server (Progressive Download), Windows Media Hardware Profiles, PocketPC, or File Archive. Refer to the "Choosing the Distribution Content Method" sidebar for more details. Click Next to continue.
4. | The next screen will prompt you for the encoding options. The various bit rate for encoding will be shown, displaying Total Bit Rate, Frame Rate, and Output Size. Choose the desired bit rate or bit rates and click Next to continue.
5. | Optional information can be added to the captured file, such as title, author, copyright information, rating, and description. Enter the desired information and click Next to continue.
6. | The next screen gives you the option to begin the capture when the Finish button is clicked, or to simply finish the configuration and start the session later. Make the appropriate selection and click Finish.

After the file has been converted, it can be played back by opening the file with Windows Media Player or another video playback tool.


Using Microsoft Producer for Sophisticated Presentations

You can use Microsoft Producer to create automated PowerPoint presentations with audio and video content. Slide presentations can be linked to a video of the presenter, as well as audio of the presentation with synchronization between slides and rich content.

Downloading and Installing Microsoft Producer

Microsoft Producer for Microsoft Office PowerPoint 2003 can be downloaded free at http://www.microsoft.com/downloads/details.aspx?familyid=1B3C76D5-FC75-4F99-94BC-784919468E73&displaylang=en. The program works with PowerPoint 2003 or PowerPoint XP (2002).

Once downloaded, run the MSPROD2.EXE file to install the software. The installation options are as follows:

1. | Click Next to continue past the Welcome page.
2. | Enter the user and organization names, and then choose whether you want to install the software for anyone who uses the computer or for just the user of the current session. Click Next.
3. | Upon reading and accepting the licensing agreement, click the I Accept the Terms pf This Agreement check box and click Next.
4. | Choose either a Typical Installation or Custom Installation. The Typical Installation option installs the two components that come with the tool, so there is usually no reason to choose Custom Installation. Click Next to continue.
5. | Click Install to complete the installation. Click Finish when prompted.

Using the Microsoft Producer Add-on

Once installed, you can launch Microsoft Producer and create a media-integrated presentation file. Do the following:

1.
To launch Microsoft Producer, select Start, Programs, Microsoft Office, Microsoft Producer.

2.
Choose Use the New Presentation Wizard to begin a Microsoft Producer project.

3.
Click Next at the Welcome screen.

4.
Choose one of the presentation templates. If you're unsure which to use, start with the default template and then try some of the other options. Click Next to continue.

Note

If you just want audio with a PowerPoint presentation deck, the Standard Audio - Resizable Slides template option provides a left pane where the audio can be controlled, and a right pane where the slide size can be changed based on the resolution of the user's monitor.

The Standard Video (320x240) - Resizable Slides template option provides a video section in the upper-left corner, session controls also in the left pane, and a resizable slide area on the right side.

5.
Select the font, size, color, and background for the table of contents, as well as any slide area background file. Click Next to continue.

6.
Enter the title for the presentation, along with any information about the presenter, introduction page image, and description. Click Preview to see what the intro page will look like, and click Next to continue.

7.
Select the path and slides that will be part of this project. This can be in the PPT and PPS presentation formats, or in the JPG, JPEG, JPE, GIF, PNG, BMP, TIF, DIB, WMF, or EMF image formats. You can select multiple files and images. Click Next to continue.

8.
Select the path and files for the audio and video files that will be part of this project. The files can be in the AVI, MPG, M1V, MP2, MP2V, MPEG, MPE, MPV2, WM, WMV, and ASF video formats, or in the WAV, AIF, AIFF, AIFC, SND, MP3, AU, MPA, WMA, and ASF audio formats. You can select multiple audio and video files, and you can even click the Capture button to capture real-time content. Click Next to continue.

9.
You are prompted with an option to synchronize your presentation slides and audio/video content. Typically, you will select Yes so you can organize the content with the appropriate rich media and slides. Click Next. Click Finish to begin importing presentation decks, slides, audio, and video content.

10.
On the Synchronize Slide page, click the Play button to start the video/audio content. Click the Next Slide button when the video/audio connects with the desired slide. The Microsoft Producer interface is shown in Figure 37.9.

Figure 37.9. The Microsoft Producer synchronization interface.

[View full size image]

After the project has been completed, the project can be saved as a Microsoft Producer file for future modifications or changes. Additionally, one of the major functions of Microsoft Producer is to publish the integrated presentation. The published presentation is saved in JPEG and WMV files that can be viewed using a standard browser.

To publish the presentation file, do the following:

1. | From the Microsoft Producer screen, select File, Publish.
2. | For the playback site, choose either My Computer, My Network Places, or Web Server. Click Next. Note Choose My Computer to publish the presentation to a file that can then be burned to CD or DVD, or accessed from a standard file server. Choose My Network Places to publish the presentation to a network share or a SharePoint Portal, or Windows SharePoint Services share. Choose Web Server to publish the presentation to a Web server, so that Microsoft Publisher content can be stored on a Web server, and the media content is stored on a Windows Media Server system.
3. | Enter the filename and the location where the files are to be published. Click Next.
4. | Confirm the title, presenter, introduction page image, and description for the Presentation Information page. Click Next.
5. | For published settings, select the Choose Publish Settings for Different Audiences option instead of the recommended Use Suggested Settings option so you can select the quality and transfer speed of the content. Click Next to continue. Note As noted in the "Choosing the Bit Rate(s)" sidebar, select the bit rate that meets the available bandwidth being used for the playback. If you plan to burn the presentation to CD-ROM, keep the content small enough to fit on a CD-ROM disc. If you plan to publish the session over the Internet, you need to choose the bandwidth available for your remote client connections.
6. | Click Next on the Publish Your Presentation screen to process the presentation.


Summary

Windows Media Services is a combination of server components and tools that help organizations go beyond text-based communications to include audio and video communications. Windows Media Services is a component that comes with Windows Server 2003 and can easily be enabled on a server system. However, the server component is predominantly a publishing and distribution functionit relies on add-ins such as the Windows Media Encoder to provide capture and conversion functionality.

Even with what Microsoft provides in the Windows Media Services server function and the Windows Media Encoder download tools, there's still a need for third-party editing and cropping tools. And with add-ons like Microsoft Producer, captured video and audio content can be integrated with Microsoft PowerPoint presentations.

Windows Media Services provides a new way for organizations to conduct employee training and broadcast live meetings, and integrate audio and video content into normal PowerPoint presentations.


Best Practices

  • For faster performance on a Windows Media Services system, place the system and application files on one hard drive set, and place the data files stored on a separate hard drive set.

  • Use the Windows Media Load Simulator to test the real-time performance capabilities of a Windows Media Services system.

  • To run Multicast broadcasting, a Windows Media Services system needs to run the Enterprise Edition of Windows Server 2003.

  • Use standard DNS characters (AZ, az, 09, and the minus sign) for publishing point names so that when you need to access the published access, you can access it over the Internet.

  • If you are publishing a broadcast to dozens of users over a network infrastructure that supports Multicast broadcasting, use the Multicast function of Windows Media Services to minimize system bandwidth demands.

  • Use the loop function in the video playback options if the video you are publishing should run continuously, such as in public kiosks or advertising systems.

  • Combine files for publishing by using the playlist function in the Windows Media Services MMC Publishing Point Configuration option.

  • Download the Windows Media Encoder to access freely available file capture and conversion tools.

  • Run the Windows Media Encoder on a system with as much RAM memory, processing speed, and disk space as possible. When a system is underpowered, a video capture or conversion might be forced to drop frames and ultimately lower the quality of the video.

  • When capturing content using the Windows Media Encoder, ensure that the microphone has been turned on to properly capture audio content because the microphone is normally disabled by default.

  • Select a bit rate for capture and conversion that matches the needs of the users. Although the highest quality may be preferable, the bandwidth demands of multiple users accessing the content at high quality may saturate the available network bandwidth.

  • Use the Microsoft Producer add-in to Microsoft PowerPoint to synchronize audio and video content with slides and PowerPoint presentations for high-quality automatic presentation playback sessions.


Appendix

    License Agreement

    Microsoft Software


License Agreement

By opening this package, you are also agreeing to be bound by the following agreement:

You may not copy or redistribute the entire CD-ROM as a whole. Copying and redistribution of individual software programs on the CD-ROM is governed by terms set by individual copyright holders.

The installer and code from the authors are copyrighted by the publisher and the authors. Individual programs and other items on the CD-ROM are copyrighted or are under an Open Source license by their various authors or other copyright holders.

This software is sold as-is without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. Neither the publisher nor its dealers or distributors assumes any liability for any alleged or actual damages arising from the use of this program. (Some states do not allow for the exclusion of implied warranties, so the exclusion may not apply to you.)


Microsoft Software

This Software was reproduced by Sams Publishing under a special arrangement with Microsoft Corporation. For this reason, Sams Publishing is responsible for the product warranty and support. If your disc is defective, please return it to Sams Publishing, which will arrange for its replacement. PLEASE DO NOT RETURN IT TO MICROSOFT CORPORATION. Any product support will be provided, if at all, by Sams Publishing. PLEASE DO NOT CONTACT MICROSOFT CORPORATION FOR PRODUCT SUPPORT. End users of this Microsoft Software shall not be considered "registered owners" of a Microsoft product and therefore shall not be eligible for upgrades, promotions or other benefits available to "registered owners" of Microsoft products.

Note

This CD-ROM uses long and mixed-case filenames requiring the use of a protected-mode CD-ROM Driver.


Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]


SYMBOL

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

% Disk Time counter
% Processor Time counter
. (dots), DNS
.. command
100/100 failover approach
32-bit Windows RDP clients, Terminal Services access
4 parameter
PING command
Tracert utility
50/50 failover approach
6 parameter
PING command
Tracert utility
6to4 technology
80/20 failover approach
99.999% uptime
? command


A

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

a parameter
Arp
DCDIAG 2nd
Netstat
PING command
A records [See host records.]
AAA (Authentication, Authorization, and Accounting)
AAAA records
access [See also servers, remote access.]
administrative
auditing
directory service, monitoring
logins
restricting
smartcards
networks, security
objects, monitoring
offline folder
physical access, restricting
resource access, monitoring 2nd
SharePoint
Terminal Services 2nd
Access Control Entries (ACEs)
account domains
account logon events, monitoring
account management, monitoring
account policies, security
Account Policy settings, Group Policies
account provisioning, MIIS
accounts
.NET Passport
Cluster Service
computer, migrating 2nd
domain
migrating
names
master account list
service
migrating into AD
MOM
test user
user accounts, migrating
ACEs (Access Control Entries)
ACT (Application Compatibility toolkit)
activating
TS License servers
Windows Server 2003
Active Directory [See schemas, AD.]
Active Directory Federation Services (ADFS) 2nd
Active Directory in Application Mode (ADAM) 2nd
Active Directory Installation Wizard
Active Directory Migration Tool [See ADMT (Active Directory Migration Tool).]
Active Directory Services Interface [See ADSI (Active Directory Service Interfaces).]
Active Directory Users and Computers MMC Snap-in
active screens
Active Server Pages [See ASP (Active Server Pages).]
active/active clustering
active/passive clustering
ActivePerl 5.6 (SFU)
ActiveX Data Objects [See ADO (ActiveX Data Objects).]
AD (Active Directory)
ADAM (Active Directory in Application Mode)
administering
administrative enhancements
administrative tools
ADSI Edit MMC Snap-in
authentication modes
Cache % Hit (performance counter)
Cache Page Fault Stalls/sec (performance counter)
Cache Page Faults/sec (performance counter)
Cache Size (performance counter)
changes in Windows .NET Server 2003
components
Computers folders, objects
Container class objects
cross-forest transitive trusts 2nd 3rd
CYS (Configure Your Server) Wizard
databases
defragmenting
locations
maintenance
databases, recovering
authoritative restore
global catalog
nonauthoritative restore
partial authoritative restore
SYSVOL folder
DCs (domain controllers), multi-master replication
DDNS (Dynamic DNS)
design features (new)
designing
development
DNS (Domain Name System) 2nd 3rd
impact
non-Microsoft implementations
secondary zones
SRV records
zones 2nd
documentation
domain rename tool
domain trees
domain trusts
domains
cross-forest transitive trusts
designing
explicit trusts
namespaces
placeholder structure
published namespaces
renaming 2nd 3rd
shortcut trusts
special-purpose
structure, choosing
trusts
Exchange 2000, scripting
Exchange 5.5
federated forests 2nd
Folder icon
forests
domain controllers
trees
FTP
functional levels
GCs (global catalog servers)
global catalog
media, creating
placement
group designs
Group Policy Object Editor, opening
groups 2nd 3rd
business function-based designs 2nd
creating
design model samples
distribution
distribution groups
domain functionality levels
domain local 2nd 3rd
forest user administration
geographical-based designs
global 2nd 3rd
local
machine local 2nd
mail-enabled groups
managing
OUs (organizational units), comparing
populating
scopes 2nd
security
security groups
single domain user administration
structure designs
types of
universal 2nd 3rd
Internet Information Server and Site Server
Internet standards, Microsoft adoption
ISTG
Kerberos
LDAP (Lightweight Directory Access Protocol) 2nd
migrating
computer accounts
NT4 groups
service accounts
mixed domain functional level
monitoring
multiple domain model
multivalued attribute replication
new features
NIS users, adding
ntdsutil utility
NTLM (NT LAN Manager)
objects
removing
scripting
OM (operations master) roles
organizational structure
OUs (organizational units) 2nd
administration, delegating
business function-based designs
design flexibility
design model samples
designs
domain designs
domains and, comparing
geographical-based designs
LDAP (Lightweight Directory Access Protocol)
mapping designs
objects
structure
structure design
peer-root domain model
performance counters
placeholder domain model
recovering
replication 2nd
collisions
connection objects
IP
latency
monitoring
multimaster
property version numbers
SMTP
update sequence numbers
replication compression, disabling
Restore mode password
schema
attributes, deactivating
customizing
extending
modifying with ADSI (Active Directory Service Interfaces)
objects 2nd
upgrading
Schema MMC Snap-in
scripting
searching
security 2nd
services
single domain model
single forest model
sites 2nd
automatic assignment
components
configuring
control
costs 2nd
creating
design
domain controllers, adding
domain controllers, promoting
encrypted SMTP
establishing
ISTG
KCC
licensing configuration
licensing server
lingering objects
link bridgeheads
link bridging
linked-value replication
links 2nd 3rd 4th
multiple-site design
replication compression
replication schedules
schema changes
single-design
Site Group Policies
SMTP replication
structure
subnets 2nd 3rd 4th
topology examples
universal group caching
Windows Server 2003 improvements 2nd
structure
subdomains
TCP/IP (Transmission Control Protocol/Internet Protocol)
universal group caching 2nd
universal group memberships, replicating
upgrading
users
attributes, populating
creating
Users folders, objects
Windows .NET Interim mode (interim domain functional level)
Windows 2000 AD forest Mixed-Mode Domain Redirect upgrade
existing forest, retiring
NT PDC promotion
OM roles
production domain controllers
re-establishing domain controllers
requirements
secondary temporary server
temporary domain controllers
Windows 2000 AD forest upgrades
AD-Integrated DNS zones, moving
domain controller migration
domain controller upgrade
functional levels, upgrading
ghost domain controllers
OM roles
replacing domain controllers
retiring domain controllers
schema upgrade
Windows 2000 Native mode (native domain functional level)
Windows NT 4.0 domains, limitations
Windows Server 2003 domain functional level
X.500 directory services
zombies, detecting
AD Users and Computers MMC snap-in, Terminal Servers
AD-integrated DNS zones
moving
standard DNS zones, comparing
ADAM (Active Directory in Application Mode) 2nd
Add Account Partner Wizard
add alias command
Add Applications Wizard
add helper command
Add Nodes Wizard
add parameter
Add Publishing Point Wizard
Add Resource Partner Wizard
add-in applications, running
Add/Remove Programs
IIS6, installing
Registry cleaning
Add/Remove Snap-in command (File menu)
adding
domain controllers, AD sites
nodes
clusters
NLB clusters
product keys
targets, DFS
WMI Filters, Group Policies
Address Expression dialog box
Address resolution protocol (Arp)
Address translations window
addresses
FQDN
Internet
IP 2nd
IPv6
NAT (Network Address Translation)
restricting
addressing
APIPA
networks
ADFS (Active Directory Federation Services) 2nd
components
installing
wizards
Admin services (IIS 6)
administration
Active Directory 2nd
AD sites
components
configuring
control
creating
domain controllers, adding
licensing configuration
licensing server
links 2nd
Site Group Policies
subnets
subnets, creating
directories, scripts
MOM
OUs, delegating
remote, Terminal Services
SFU
users 2nd
VPNs
Windows Server 2003 benefits
File Server Resource Manager (FSRM)
global catalog servers, building
IPSec NAT Transversal
Print Management Console (PMC)
Volume Shadow Copy
administration documentation
administrative access
administrative controls, security policies
administrative delegation, DHCP
administrative model
administrative templates 2nd
add-on
baseline Outlook preferences
customizing 2nd
delegates
managing
Outlook 2nd
Outlook client look and feel
Outlook clients
Policies versus preferences
rights, assigning
administrative utilities
Active Directory
dragging and dropping
administrator passwords
changing
configuring
administrator workstations
ADMT (Active Directory Migration Tool) 2nd 3rd
account state options
domain migration
computer accounts, migrating 2nd
domain accounts, migrating
domain policies
groups, migrating
OU
password keys
password migration DLL
permissions
Registry permissions
requirements
two-way trusts
user accounts, migrating
functions
installing 2nd
lab environment
naming conflicts
NT4 group migrations
options
requirements
service account migrations
ADMT User Account Migration Wizard
ADO (ActiveX Data Objects)
Adobe Acrobat Web site
adprep utility, AD schema upgrades
ADS (Automated Deployment Services)
ADSI (Active Directory Service Interfaces) 2nd
ADSI Edit MMC Snap-in
ADSPath attribute 2nd
ADuser.vbs script
advanced mode
ASR
ASR backups
ASR tips
Backup
Advanced startup options
advertising test
agents
management
MOM 2nd 3rd
relay, DHCP
SNMP, RRAS
agreements, SLAs (service-level agreements)
alerts
MOM
SharePoint
aliases
all parameter, Ipconfig utility
All Users user profiles
allocating
hardware, compatibility testing
Windows Server 2003, compatibility testing
alternate DHCP clients
an parameter, Netstat
analysis [See also capacity analysis.]
event logs
processor usage
Security Log
announcement files, creating
announcements, SharePoint list of
anomaly-based detection
anonymous authentication
antivirus programs
Terminal Server mode
APIPA (Automatic Private IP Addressing) 2nd
APIs (Application Programming Interface) 2nd
applets
Add/Remove Programs, Registry cleaning
Licensing
Application Compatibility Analyzer 2nd
Application Compatibility toolkit [See ACT (Application Compatibility toolkit).]
application logs 2nd
application management packs
Application Programming Interfaces (APIs) 2nd
application servers
cluster servers
DFS (Distributed File Systems) server
DHCP (Dynamic Host Configuration Protocol) server
DNS (domain name service) server
domain controller
functions
global catalog server
media servers
remote access servers
terminal servers
Web servers
application service providers, Terminal Services
application-level security policies
applications [See also programs.]
add-ins, running
Cluster Service, selecting
cluster-aware
cluster-unaware
configuring
CPU utilization
CRM (client relationship management)
dependencies
desktop
handlers/worker processes
hosted, Terminal Services, planning
idle timeout
IIS 6 process recycling
installing 2nd 3rd
inventory
inventory sheets
isolating
monitoring
Task Manager
with IIS 6
NLB clusters
optimizing
options
partitions, AD-integrated DNS zones
performance
pooling 2nd
prioritizing
publishing
queues
readiness, single server upgrades
recycling configurations
reliability
running
services, compared
user requirements
Web Gardens
Web sites, configuration options
Web, server settings
Web-based, .NET Passport integration
Windows .NET Application Host
Applications tab (Task Manager window)
AppManager Suite Web site
approving
D/R solution
WSUS updates
architectures
MOM
MSDSS
Registry
hives
HKEY_CLASSES_ROOT hive 2nd
HKEY_CURRENT_CONFIG hive 2nd
HKEY_CURRENT_USER hive 2nd
HKEY_LOCAL_MACHINE hive
HKEY_USERS hive 2nd
keys and subkeys
locations
storage
archive event logs, checking
archived file copies, user-level retrieval
archiving
data
events
Areas window
Arp (Address resolution protocol)
as-built documents
ASDI
ASP (Active Server Pages)
ASP.NET
ASR (Automatic Server Recovery) 2nd 3rd 4th
Backup utility
backups, creating
clusters
Registry, backing up
restore
failed nodes
system recovery
tips
assigning scripts
associations, file (HKEY_CLASSES_ROOT hive)
attribute flow function
attributes
ADSPath 2nd
directories
objects
ProfilePath
SamAccountName
schemas, deactivating
users, directory names
audio
presentations
redirection
audit events, reading
auditing
access, file-level security
environments
logon/logoff events
policies
resource access 2nd
files
folders
IIS 6 security
internal security 2nd
NTFS folders
Registry
system events
authentication
.NET Passport
anonymous
basic
digest
FTP, securing
IIS 6 security
integrated Windows
.NET Passport
protocols
authentication and accounting logging
Authentication Methods dialog box
authentication modes, Active Directory
Authentication, Authorization, and Accounting (AAA)
authoritative restores
authorization 2nd
Auto Update
Automated Deployment Services [See ADS (Automated Deployment Services).]
Automated System Recovery Preparation Wizard
Automated System Recovery Wizard
Automatic Private IP Addressing [See APIPA (Automatic Private IP Addressing).]
Automatic Server Recovery [See advanced mode, ASR.]
Automatic Updates Client 2nd
automating patch management
automating tasks [See scripting.]
Avg. Disk Queue Length counter
AXFR (full zone transfers)
AXFR Request Received (DNS zone transfer counter)
AXFR Request Sent (DNS zone transfer counter)
AXFR Response Received (DNS zone transfer counter)
AXFR Success Received (DNS zone transfer counter)
AXFR Success Sent (DNS zone transfer counter)


B

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

background information of networks, design documents
Background Intelligent Transfer Service (BITS) 2nd
backup documents
backup domain controllers (BDCs), migrating 2nd
backup pools
backup security
Backup utility
advanced mode
ASR
modes
Registry, backing up
VSS
Backup Wizard 2nd
backups
ASR, creating
CA
Certificate Services
clusters
ASR
node local disks
node system state
nodes
quorum
shared disks
DFS 2nd
DHCP 2nd
disk configurations
DNS
files
Group Policies 2nd
IIS metabase 2nd
MOM
NLB nodes
online, open files
operating system
Registry
ASR
Backup Utility
keys
Remote Storage 2nd
Removable Storage Service
restores, testing
server upgrades
services
Certificate Services
DFS
DHCP databases
disk configuration
DNS
IIS metabase
Remote Storage Service
Removable Storage Service
WINS
strategies
utilities
validating
verification
WINS 2nd
balancing (load)
bandwidth, reduced available
BAP (Bandwidth Allocation Protocol)
bare minimum services (disaster recovery)
base installation security policies
baselines
benchmark
documentation
metric, establishing
monitoring overhead
objects, monitoring
Outlook preferences
policy, establishing
procedure, establishing
basic authentication
basic compatibility testing
basic disks
converting to dynamic disks
basic partitions
basic volumes
BDCs (backup domain controllers)
benchmark baselines
binary values
bit rates, media content
BITS (Background Intelligent Transfer Service) 2nd
block policy inheritance 2nd 3rd
BMC Software Web site
BoilSoft utilities
boot disks, creating
boot failures, recovering from
boot loader files, restoring
boot volumes
backing up
disk failures
BOOTP (Bootstrap Protocol)
bottlenecks (performance)
branch offices, connecting
bridgeheads, AD site links 2nd
bridging AD site links
broadcast publishing points, playlists
broadcast publishing, compared to on-demand publishing
broadcasts
captured broadcasts
live
Media Services configuration
starting
playlists
broadcast publishing points
configuring 2nd
on-demand publishing points
starting
single video
configuring
on-demand
publishing points
browsers, IE (security)
budgets
compatibility testing
estimating
design documents
migration documents
built-in toolsets for capacity analysis
Network Monitor
Performance Console
Task Manager
Burton Group
business function-based designs
business goals and objectives, identifying
bye command


C

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

c parameter, DCDIAG 2nd
CA (Certificate Authority) 2nd
backing up
certificates, restoring
databases, restoring
private keys, restoring
SSL certificates, requesting
Cache % Hit (Active Directory performance counter)
Cache Page Fault Stalls/sec (Active Directory performance counter)
Cache Page Faults/sec (Active Directory performance counter)
Cache Size (Active Directory performance counter)
caching
client, DNS troubleshooting
client-side, file shares
global catalog information
universal groups 2nd 3rd
caching-only servers
calendaring, Outlook
CALs (Client Access Licenses) 2nd 3rd
Canonical Name records (CNAME)
capacity analysis
% Disk Time counter
% Processor Time counter
AppManager Suite Web site
Avg. Disk Queue Length
benchmark baselines, establishing
benefits
BMC Software Web site
bottlenecks
built-in toolsets
Computer Associates Web site
Computer Measurement Group Web site
defining
Heroix Web site
Hewlett-Packard Web site
Information Systems Web site
Interrupts/sec counter
metric baselines, establishing
MOM (Microsoft Operations Manager)
NetIQ Corporation Web site
Network Monitor
Openview Web site
Pages/sec counter
PATROL Web site
PerfMan Web site
Performance Console 2nd
Performance Monitor
policy baselines, establishing
procedure baselines, establishing
RoboMon Web site
SMS (Systems Management Server)
Task Manager
third-party toolsets
tools
Transaction Processing Performance Council Web site
Unicenter TNG Web site
VeriTest Web site
workload characterizations
capacity limits (MOM)
Capture Filter
capture triggers, configuring
captured broadcasts
capturing
frames, Netmon
media sessions
screen content
cards, network (NLB clusters)
catalogs [See also global catalog.]
information, caching
servers 2nd
synchronization
category property, logs
CDO (Collaborative Data Objects)
CDs (Connected Directories)
centralized administration model
Certificate Authority [See CA (Certificate Authority).]
Certificate Authority Restore Wizard
certificate issuance policies
Certificate Services
backing up
installing
restoring 2nd
certificate usage
certificates [See also CA (Certificate Authority); Certificate Services.]
SSL (Secure Sockets Layer)
applying
CAs, requesting
for Web sites, requesting
IIS 6 security
certutil.exe utility
change management, disaster recovery documentation
change parameter, Route command
characterizations, workload (capacity analysis)
charts, GANTT
checklists
administration/maintenance documentation
migration documentation
security policies
CheckSDRefDom test
child domains, adding to multiple domain model
CHOICE.exe utility
classes, Container (objects)
cleaning Registry
Add Remove Programs applet
MSICUU
MSIZAP
CLFS (Common Log File System)
Client Access Licenses (CALs) 2nd 3rd
Client Authentication certificate purpose
client cache, DNS troubleshooting
client relationship management (CRM) applications
client software, installations
Client, NFS
client-side caching, file shares
client-side Terminal Services
clients [See also network clients.]
32-bit Windows RDP, Terminal Services access
Automatic Updates, configuring
connectivity, alternate methods
DHCP 2nd
IPSec policies
Outlook
look and feel
policy options
remote access
CM client dialer
CMAK
CPS
NAT Traversal
single sign-on
VPNs
RIS requirements 2nd
thin client Terminal Services
VPN
Web, Terminal Services access
CLR (Common Language Runtime)
CLUSDB file, replacing
Cluster Administrator 2nd
Cluster Automation Server
cluster servers
Cluster Service 2nd [See also clusters, DHCP servers.]
accounts
applications, selecting
cluster groups, creating
cluster groups, moving
configuring
MNS cluster
single node cluster
single quorum device cluster
failbacks
failovers
installing
first node 2nd
nodes, adding
pre-install checklist
managing
node maintenance
post-maintenance tasks
pre-maintenance tasks
nodes, deleting
passwords
recovering
resources, creating
shared storage devices
testing clusters
cluster-aware applications
cluster-unaware applications
Cluster.exe
clusters [See also Services, NLB clusters.]
active/active
active/passive
backing up
ASR
cluster node system state
node local disks
nodes
quorum
shared disks
DHCP servers
failbacks
failovers
generic resources
groups
creating
moving
heartbeat 2nd
local quorum resources
MNS
node system state, backing up
nodes
backing up
deleting
failed, evicting/rebuilding
local disks, backing up
maintenance
upgrading
quorum disks 2nd
resources 2nd 3rd
restoring
evicting/rebuilding failed nodes
failed nodes
nodes after cluster failure
previous states
single nodes with server failure
single nodes with service failure
shared disks, backing up
technologies
terminology
testing
manual failover
node network failures
resource failures
virtual servers
CM (Connection Manager)
CM (Connection Manager) client dialer
CM profiles, quarantine
CMAK (Connection Manager Administration Kit)
cmd command
CNAME (Canonical Name) records
collaboration, SharePoint
Collaborative Data Objects [See CDO (Collaborative Data Objects).]
collaborative design decisions, Windows Server 2003 migration
collisions (replication)
comma-delimited format (csv)
command-line options 2nd
command-line tools 2nd
commit command
Common Language Runtime [See CLR (Common Language Runtime).]
Common Log File System (CLFS)
compacting WINS
comparing
domains and OUs (organizational units)
groups and OUs (organizational units)
speed and risk
standard and AD-integrated DNS zones
Windows Server 2003 and Windows .NET Framework
Compatibility Check tool
compatibility testing
application inventory
application priority
applications versus services
basic
budget
checklist
complete
documentation
extent
goals
inventory application sheets
lab-testing
mid-level
network systems inventory
plan, documenting
preparations
prototype phase
resources
results, documenting
scope
testing lab
timeframe
training
user involvement
vendor information
compatible templates
complete compatibility testing
compliance criteria, .NET Passport
components
Active Directory
AD sites
ADFS (Active Directory Federation Services)
enterprise networks
IIS optional components 2nd
Quarantine Policy Check tool
registering on servers
SFU
ActivePerl 5.6
NFS
NISusers, adding to Active Directory
password synchronization
remote administration
Subsystem for Unix-based Applications
User Name Mapping
user synchronization
software, installed
compression
AD replication
disabling on high-speed links
HTTP settings
replication, disabling
computer accounts, migrating into
AD
ADMT v2.0 domain migration
Computer Associates Web site
Computer Configuration, Group Policy snap-in namespaces
Administrative Templates
Security Settings
Software Settings
Windows Settings
Computer Management tool, Terminal Services
Computer Measurement Group Web site
Computer Migration Wizard 2nd
computer names, configuring
computer policies
computer property, logs
computer startup scripts, assigning
Computers folders, objects
computers, names
ComputerToFind parameter, Nslookup
concepts, Registry
configuration groups, MOM 2nd
configuration settings, FTP
configuration wizards
configurations
application recycling
Computer Configuration, Group Policy snap-in namespaces
control set
disk subsystem
User Configuration, Group Policy snap-in namespaces
Configure a DNS Server Wizard
Configure Your Server Wizard
DNS installation
domain controllers, replacing
RRAS installation
security
ConfigureEventLogs tool
configuring
AD site licensing
AD sites
administrator passwords
applications
Automatic Updates clients
capture triggers
Cluster Service
applications, selecting
MNS cluster
shared storage devices
single node cluster
single quorum device cluster
computer names
date and time
DHCP, RIS
disk quotas
DNS, pointing to itself
domain trust
folder redirection
forest functionality levels
FTP security options
FTP services
Group Policies
Group Policy snap-in
hardware, compatibility testing
IAS
IIS 6
backup configuration settings
IIS snap-in
virtual directories
Web services, configuring
Web site properties, selecting
Web sites, creating
Web sites, selecting properties 2nd
Media Services
MOM
multiple server
single server
network cards, NLB clusters
network settings
offline folder access
operating systems
administrator passwords
computer names
date and time
existing domains, joining
languages
licensing modes
network settings
partitions, formatting
personalizing
product keys
playlist broadcasting 2nd
PMC (Print Management Component)
RDP ports
real-time live broadcasts, Media Services
Registry permissions
remote access clients
Remote Assistance
Remote Storage
backup devices
removable media
volumes
RIS
RRAS
security, Configure Your Server Wizard
session directory servers
shadow copies 2nd
single video broadcasts
slow links
SMTP Service, options
Terminal Services
AD Users and Computers MMC snap-in
Computer Management tool
Configuration MMC snap-in
Group Policy
Local Security Policy snap-in
test user accounts
trace logs
user storage limits in FSRM
video directories
virtual directories
Web services
Windows 2003 R2 components
Windows Server 2003, compatibility testing
WINS, push/pull partners
Connected Directories (CDs)
connecting remote Registries
Connection Manager (CM)
Connection Manager Administration Kit (CMAK)
connection objects, replication
connection types, specifying
connections
branch offices
flat file data sources
flat files
L2TP/IPSec, authentication protocols
PPTP, authentication
remote, Terminal Services
replication
RRAS, managing
site-to-site
Terminal Services Configuration MMC snap-in
VPNs
WAN, documenting
connectivity
clients, alternate methods
testing
Connector Namespaces (CSs)
consent levels, .NET Passport for Kids
consoles [See also MMC (Microsoft Management Console).]
Netmon
Performance
capacity analysis
disk/volume monitoring
Performance Logs and Alerts
System Monitor
trace logs
Terminal Services
consolidating NT4 domains
consolidator, MOM
Contacts
Outlook
SharePoint list of
Container class objects
control
AD sites
Nested delegation
control set configurations
controllers [See also forests, domain controllers.]
backup domain, migrating
domain, upgrading
conventions, naming GPOs (Group Policy Objects)
converting .NET Passport accounts
cookies
copies of archived files, user-level retrieval
copying
Group Policies 2nd
user profiles
costs, AD sites 2nd
counter logs
CPS
CPU utilization, applications
CRM (client relationship management) applications
cross-domain policy assignments
cross-forest transitive trusts 2nd 3rd
cross-forest trusts 2nd 3rd
CSs (Connector Namespaces)
csv (comma-delimited format)
CSV files, users, creating
Csvde.exe
CurrentTime variable
Custom Errors tab (Default Web Site Properties page)
custom media pools
custom printer filters, creating
customizing
AD Schema 2nd
administrative templates 2nd
delegates
Outlook
Outlook clients
rights, assigning
desktop
desktop images, RIS
event logs
SharePoint 2nd
topologies
Windows Server 2003 interface
WSUS
CutoffServers test


D

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

d parameter
Arp
NetDiag
Tracert utility
D-DCAM servers, MOM
D/R solution
DACLs (Discretionary Access Control Lists)
daily maintenance
backup verification
Event Viewer, monitoring
server functionality
DAS (Data Access Server)
data
archiving
DFS fault tolerance
DFS redundancies
storing MOM
Data Access Server. (DAS)
Data Encryption Standard. (DES)
data recovery
DFS
Ntbackup.exe
reparse points
shadow copies
VSC
data sources, flat file connections
data volumes
backing up
disk failures
Database object, loading
database servers
MOM
monitoring
databases
AD
defragmenting
locations
maintenance
recovering
CA, restoring
DHCP
backing up
maintaining
MOM, size
MSDE, MOM
NT4 SAM
Remote Storage, recovering
removable media, recovering
WINS
backing up
maintaining
DataCenter edition of Windows Server 2003
date and time, configuring
date property, logs
DC [See forests, domain controllers.]
DCAccountEnum parameter, NetDiag
DCAM servers, MOM
DCDiag 2nd
parameters
syntax
tests
dcpromo command
DCPromo test
DDNS (Dynamic DNS) 2nd
Active Directory
DHCP
deactivating schema attributes
debug parameter, NetDiag
debugging
Event Viewer
console tree
event archives
event filtering
event log customizations
logs
property page
remote servers
security log
system event audits
tools
Dr. Watson for Windows
memory
software error reporting
System Startup and Recovery
TCP/IP 2nd
Debugging mode
decentralized replication design example
default domain policy, group policies
.DEFAULT profile, HKEY_USERS hive
default user profiles
Default Web Site Properties page
defragmenting AD databases
Delegate Control Wizard
delegate permissions, selecting
delegates, assigning Group Policies
delegating
OU administration
tasks
delegation control, completing tasks
delegation, nested control
delete alias command
Delete dialog box
delete helper command
Delete parameter, Route command
deleting
Active Directory schema objects
cluster nodes
GPOs
lingering objects
NLB clusters
NLB nodes
objects
orphaned group policies
shadow copies 2nd
WMI Filters, Group Policies
departmental goals, identifying
dependencies
deploying
client updates, Group Policies
desktops
DFS
DFS types, selecting
domain DFS
FRS
NTFS permissions
replicating
replication topologies
Group Policy network clients
hotfixes
RIS, planning
service packs
Terminal Services
updates
Windows XP images [See images, Windows XP deployment.]
Windows XP tools, Setup Manager
deployment team participants, defining
DES (Data Encryption Standard)
descriptions, forests (XML documents)
design documents 2nd
design features (new) in Active Directory
design phase, Windows Server 2003 migration
budget estimates
collaborative design decisions
design agreements
design decisions
end state (technology configurations)
executive summaries
information overload management
network background information
project goals and objectives
solutions, implementation approach
structured design documents, organizing information
table of contents (sample)
design team participants, defining
designs
Active Directory
business function-based
distribution groups
domain-to-domain trust design sample
domains 2nd
federated forests design model
geographical-based
group structures
groups
best practices
business function-based
distribution
geographical-based
group naming standards
model samples
naming standards
nesting
OUs
universal distribution
universal groups
universal security
IIS 6
multiple domain model, real-world design example
OU structures
OUs
business function-based designs
domain designs
flexibility
geographical-based designs
group policies
mapping
model samples
peer-root domain model, real-world design example
placeholder domain model, real-world design example
projects
single domain model, real-world example
single forest model, real-world design example
special-purpose domains, real-world design example
universal distribution groups
universal security groups
WINS environment
desktop security policies
desktop software, installing
desktops
applications
Group Policy
manual installations
third-party packaging software
customizing
deploying
images
updating
migration documentation
RIS
client requirements
configuring
deployments, planning
DHCP configuration
installing
screen saver password protection
Windows XP
managing
remote management
destination parameter, Route command
devices
backup, Remote Storage
network, network configuration documentation
selecting backup strategy
shared storage, Cluster Services
DFS (Distributed File System) 2nd 3rd
backing up 2nd
DFScmd.exe utility
hierarchy
target data
benefits
data fault tolerance
data recovery
data redundancies
deploying
DFS types, selecting
domain DFS
FRS
NTFS permissions
replication
standalone DFS roots
types, selecting
DFS roots
FRS
event logging
terminology
installing
DFS root file share
links, creating
publishing DFS roots
replication
roots, creating
targets, adding
links 2nd
offline targets
optimizing
referrals
replicas, prestaging
replication
best practices
disabling
topologies, hub and spoke
roots
creating
publishing
status, monitoring
SONAR
System Monitor
targets
terminology
trees
DFS root file shares
DFS roots
DFS server
DFScmd.exe 2nd
DFSR (Distributed File System Replication)
DHCP (Dynamic Host Configuration Protocol) 2nd
administrative delegation
alternate clients
APIPA
backups
clients
database maintenance
database, backing up
DDNS
failover
100/100 approach 2nd
50/50 approach
80/20 approach
clustering
standby scopes approach
installing
maintenance
Multicast scopes
Netsh
new features
predecessors
relay agents
restoring 2nd
RIS configuration
scopes
security
servers 2nd 3rd
Superscope
DHCP Allocator window
DHCPExim utility
diagrams, triangle (domains)
digest authentication
Dim command
directories [See also Active Directory.]
administration scripts
attributes
home
integrating networks
metadirectories [See metadirectories.]
pre-install
root folders, redirecting to
Session Directory
Session, redundancy/scalability
video
configuring
files, viewing
virtual
directory administration scripts
directory names, user attributes
Directory Security tab (Default Web Site Properties page) 2nd
Directory Security tab (FTP Sites folder properties page)
directory service access, monitoring
Directory Service log
Directory Service Restore mode
directory services
Windows Server 2003
X.500
Directory Services Markup Language (DSML)
Directory Services Restore Mode, security
disable port range mode (port filtering)
disabling
compression on high-speed links
DFS replication
dynamic information
GPOs
group policy configuration settings
replication compression
Terminal Services
disaster recovery
99.999% uptime
AD
authoritative restore
database
global catalog
nonauthoritative restore
partial authoritative restore
SYSVOL folder
backup strategy
backup utilities
boot failures
cluster service
disk failures
documentation
domain controllers
environment
failures, isolating
files/folders
DFS
Ntbackup.exe
VSC
IIS
network outages
operating system backup
physical site disasters
planning
power outages
recovery documentation
Remote Storage database
removable media database 2nd
server failures 2nd
ASR restore
boot loader file
hard drive failures
manual recover
restoring vs rebuilding
software corruption
system state restore
services
Certificate Services
DHCP data
DNS zones
WINS data
site failures
Terminal Services
disaster recovery documentation 2nd
disasters
discovery phase, Windows Server 2003 migration
geographical depth and breadth
information overload management
discovery, projects
Discretionary Access Control Lists (DACLs)
discussions, SharePoint
disk arrays, fault-tolerant
basic disks
disk types
dynamic disks
formatting
managing
volumes
disk configuration, backing up
Disk Defragmenter, running
disk drives, redirecting
disk failures, recovering from
Disk Management MMC snap-in
Disk Manager, shadow copies, deleting
disk quotas, configuring
disk space, checking
disk subsystems 2nd
Diskeeper
Diskpart.exe utility
disks
basic, converting to dynamic disks
boot, creating
dynamic
basic disk conversions
fault-tolerant disk volumes
formatting
local, cluster nodes, backing up
Logical Disk object
managing
monitoring
Physical Disk object
quorum
shared clusters, backing up
displaydns parameter, Ipconfig utility
displaying Registry hives
displays, System Monitor
distinguished names (Active Directory)
distributed administration model
Distributed File System [See DFS server.]
Distributed File System Replication (DFSR)
distribution groups 2nd 3rd
distribution, media content
DLLs, installing password migration
DNS (Domain Name System) 2nd 3rd
Active Directory 2nd
and foreign DNS, co-existing
impact
non-Microsoft implementations
secondary zones
SRV records
AD-Integrated DNS zones, moving
AXFR (full zone transfers)
AXFR Request Received (zone transfer counter)
AXFR Request Sent (zone transfer counter)
AXFR Response Received (zone transfer counter)
AXFR Success Received (zone transfer counter)
AXFR Success Sent (zone transfer counter)
backing up
configuring, pointing to itself
DDNS, DHCP
dynamic
Dynamic Update Received/Sec counter
dynamic updates
forwarders
hierarchy
history
installing Configure Your Server Wizard
island problem
IXFR (incremental zone transfers)
IXFR Request Received (zone transfer counter)
IXFR Request Sent (zone transfer counter)
IXFR Response Received (zone transfer counter)
IXFR Success Received (zone transfer counter)
IXFR Success Sent (zone transfer counter)
maintenance
monitoring
msdcs subdomain
namespaces 2nd
overview
performance counters
queries
Recursive Queries/Sec counter
Recursive Query Failure/Sec counter
root 2nd
RRs
scavenging
Secure Update Received/Sec/Sec counter
secure updates
subdomains
TCP Query Received/Sec counter
TCP Response Sent/Sec counter
Total Query Received/Sec counter
Total Response Sent/Sec counter
troubleshooting
TTL
UDP Query Received/Sec counter
UDP Response Sent/Sec counter
Unicode character support
WINS integration
WINS lookups
zone transfers
zones
AD-integrated 2nd
automatic creation
forward lookup
integrated
primary
restoring
reverse lookup
secondary
standard and AD-integrated, comparing
storing
stub
DNS Proxy information window
DNS server
DNS Server log
DNSCMD utility, DNS troubleshooting
Do Not Rename Accounts option (ADMT)
document libraries, SharePoint
documentation
AD
administration
baselining
benefits
compatibility testing
design
disaster recovery
enterprise
financial benefits
firewall configurations
hardware inventory
knowledge management
maintenance
migration
network configuration 2nd
performance
of pilot results of migration process
recovery 2nd
reviewing
router configurations
security
server build
server configurations
switches configurations
training
troubleshooting
types
updating
WAN connections
documented instruction scripts
documents
backup
design 2nd
DR (disaster recovery)
managing SharePoint
migration 2nd
procedural
recovery
structured design
XML, forest descriptions
Documents tab (Default Web Site Properties page)
domain accounts
migrating ADMT 2nd
names
Domain Controller Diagnostic tool [See DCDiag, syntax.]
domain controllers (DC)
Active Directory
adding AD sites
forests
monitoring
multi-master replication
replication, monitoring
AXFR Request Received (DNS zone transfer counter)
AXFR Request Sent (DNS zone transfer counter)
AXFR Response Received (DNS zone transfer counter)
AXFR Success Received (DNS zone transfer counter)
AXFR Success Sent (DNS zone transfer counter)
BDCs (backup domain controllers)
DHCP
DNS (domain name system), monitoring
Dynamic Update Received/Sec (DNS performance counter)
GC/DCs 2nd
ghost, retiring
global catalog information, caching
IXFR Request Received (DNS zone transfer counter)
IXFR Request Sent (DNS zone transfer counter)
IXFR Response Received (DNS zone transfer counter)
IXFR Success Received (DNS zone transfer counter)
IXFR Success Sent (DNS zone transfer counter)
migrating
monitoring
performance counters
performance optimization
production, demoting
promoting
re-establishing
recovering
Recursive Queries/Sec (DNS performance counter)
Recursive Query Failure/Sec (DNS performance counter)
replacing
retiring
Secure Update Received/Sec/Sec (DNS performance counter)
server management
TCP Query Received/Sec (DNS performance counter)
TCP Response Sent/Sec (DNS performance counter)
temporary
Mixed-Mode Domain Redirect AD forest upgrades
retiring
temporary NT, Mixed-Mode Domain Redirect AD forest upgrades
Total Query Received/Sec (DNS performance counter)
Total Response Sent/Sec (DNS performance counter)
UDP Query Received/Sec (DNS performance counter)
UDP Response Sent/Sec (DNS performance counter)
upgrading 2nd
zone transfer counters
domain DFS
domain functional level
domain functional level (Windows Server 2003)
domain functionality levels, groups
domain local groups 2nd 3rd
domain member servers, migrating
Domain Name System [See DNS server.]
domain naming master (OM role)
domain policies, ADMT v2.0 domain migration
domain printers, finding script
domain rename utility
domain servers, volume free space script
domain trusts (Active Directory)
cross-forest trusts
explicit trusts
external trusts
replacing with OUs
transitive trusts
domain-to-domain trusts, trust design sample
domains [See also DNS (Domain Name System).]
account/resources
Active Directory
child, adding to multiple domain model
cross-forest transitive trusts
DDNS (Dynamic DNS)
designing 2nd
explicit trusts
installing
joining
migrating ADMT v2.0. [See permissions, ADMT v2.0 domain migration.]
multiple domain model
names 2nd
namespaces
native mode, universal groups
NT4
OUs (organizational units), comparing
placeholder domain model
rename tool
renaming 2nd 3rd 4th
resource, Windows NT4
root, cross-forest trusts
shortcut trusts
single domain model
special-purpose
structure, choosing
subdomains
in Active Directory
shortcut trust
transitive trusts
triangle diagram
trusts 2nd
Windows .NET Server 2003 single domain with OUs (organizational units)
Windows .NET, Interim mode (interim domain functional level)
Windows 2000, Native mode (native domain functional level)
Windows NT 4.0, limitations
Windows NT resource domain layouts, mapping OU designs
Windows NT4 structure
dots (.), DNS
dotted-decimal format
downloading
ADS
encryption keys
Feature Packs
tools
downtime
DR (disaster recovery) document
Dr. Watson for Windows
drivers
IP filtering
IPX filtering
IPX forwarder
printer drivers, updating
signing
drives, local (redirection)
drizzling
DSML (Directory Services Markup Language)
dump command
DWORD values
dynamic disks
basic disk conversions
fault-tolerant disk volumes 2nd
Dynamic DNS [See DDNS (Dynamic DNS).]
Dynamic Host Configuration Protocol [See DHCP (Dynamic Host Configuration Protocol).]
dynamic information, enabling or disabling
Dynamic Interface Manager, RRAS
dynamic IP addresses
Dynamic Update Received/Sec (DNS performance counter)
dynamic updates, DNS
dynamic volumes


E

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

e parameter
DCDIAG 2nd
Netstat
e-mail, mail-enabled groups
EAP (Extensive Authentication Protocol)
EAP-TLS authentication protocols
editing
GPOs
metabases
SharePoint lists
video, tools
editions of Windows Server 2003
editors [See also Group Policy Object Editor; Registry Editor.]
education, security policies
EFS (Encrypting File System) 2nd 3rd
email settings, Outlook
Emergency Management Services Console, troubleshooting startup
employee forms
emulators, PDC Emulator (OM role)
enable boot logging mode
Enable VGA mode
enabling dynamic information
Encrypting File System (EFS) 2nd
encryption
files 2nd
folders
private keys
public keys
SMTP
encryption keys
end state (technology configurations)
end-user satisfaction, verifying
end-user training
Enforcement feature, group policies
enforcing security policies
Enhanced Security Configuration (Internet Explorer) 2nd 3rd
enterprise documentation
Enterprise edition of Windows Server 2003
enterprise networks
enterprise root CA 2nd
enterprise security policies
enterprise subordinate CA 2nd
enterprise-level security policies
entries (Registry Editor)
environments
auditing
logon/logoff events
policies
resource access 2nd
disaster recovery
Windows Server 2003, supporting
WINS
errors
software, reporting
Windows XP images
ESE (Extensible Storage Engine)
estimating budgets
design documents
migration documents
evaluations, disk subsystems
Event Comb utility
event logs
analyzing
archiving 2nd 3rd
customizing
FRS
retrieving
security
event property, logs
Event Viewer
console tree
DNS troubleshooting
event archives
event filtering
event log customizations
logs
monitoring 2nd
property page
remote servers
security log
system event audits
events
account logon, monitoring
archiving
audit, reading
filtering 2nd
logon/logoff
processing MOM
properties
SharePoint list of
system
auditing
monitoring
EventSim (Event Simulations tool)
evt (log-file format)
Exchange 2000, AD, scripting
Exchange 5.5
exec command
executive summaries
design documents
migration documents
exit command
expandable string values
explicit trusts 2nd
Explorer View, libraries
exporting WMI Filters, Group Policies
Extended Management Packs [See management packs, XMPs.]
extending Active Directory schema
Extensible Authentication Protocol-Transport Level Protocol (EAP-TLS)
Extensible Rights Markup Language (XrML)
Extensible Storage Engine
extensions
video files
Web services, locking down
Extensive Authentication Protocol (EAP)
external namespaces 2nd
external trusts


F

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

f command-line parameter
DCDIAG 2nd
PING command
Route command
failbacks
Cluster Service
clusters
failed nodes
evicting/rebuilding
restoring
failover sites
failovers
Cluster Service
clusters
DHCP
disaster recovery documentation
MOM
failures [See also system volumes, disk failures.]
boot, recovering from
cluster resources, testing
hard drive
isolating
node network, testing
server
hard drive failures
recovering from
software corruption
site
creating
failing back
failing over between sites
failover sites
planning
redundant sites
validating
Fair Information Practices (FIP)
FAT (File Allocation Table)
fault tolerance
DFS data
disk arrays
basic disks
disk types
dynamic disks
formatting
managing
volumes
IIS 6 requirements, determining
systems
application reliability
creating
network hardware
server storage
UPSs
Terminal Services 2nd 3rd
tier environments
volumes, creating
faults, hard and soft memory
Favorites menu (Registry Editor)
Feature Packs
features (new) of Windows Server 2003
Active Directory schema objects, deleting
configuration wizards
dragging and dropping
functionality improvements
global catalog information, caching
global catalog synchronization
high-speed links, disabling compression
IETF security standards, supporting
interfaces, customizing and programming
IPv6 standard, supporting
management wizards
performance improvements
security improvements
setup wizards
standards, supporting
tasks, simplifying
visual changes
XML Web Services, supporting
federated forests
federated forests design model
Federation Proxy Server (ADFS)
Federation Server (ADFS)
ferr parameter, DCDIAG 2nd
File Allocation Table (FAT)
File and Print Services for NetWare (FPNW) 2nd
file associations, HKEY_CLASSES_ROOT hive
file data, scripting users from
File menu commands, Add/Remove Snap-in
File Migration Utility (FMU) 2nd
File Protection
File Replication Service [See file systems, FRS.]
File Replication Service log
file screen templates, creating in FSRM
file screens, creating in FSRM
File Server Resource Manager [See FSRM (File Server Resource Manager).]
file servers 2nd 3rd
file shares
client-side caching
data recovery
DFS root
managing
permissions
File Signature Verification
file systems
DFS [See DFS server.]
DFSR
File Protection
FRS
integrity, maintenance
remote storage
security
VSS
file-level security
access audits
encryption
NTFS
FileReplicaConn object
FileReplicaSet object
files
announcements, creating
archived copies, user-level retrieval
auditing
backing up
boot loaders, restoring
CLUSDB, replacing
CSV, users (creating)
DFS (Distributed File System)
encrypting 2nd
flat, connections
formats
HOST, DNS troubleshooting
LMHOSTS
logarchive.ini
logon.bat, adding as startup scripts
logs [See logs.]
media-integrated presentation
monitoring
offline
open, online backups
recovering
DFS
Ntbackup.exe
VSC
replication management tools
storage management, FSRM
tracing
unattend.bat example
uploading SharePoint
video
converting
extensions
video directories, viewing
filtering modes, NLB clusters
filters
Capture
events filtering 2nd
printer filters, creating custom
pull record filtering
WMI
FIP (Fair Information Practices)
firewalls 2nd
configurations, documenting
MOM
Terminal Services
first nodes, installing 2nd
five nines uptime
fix parameter
DCDIAG 2nd
NetDiag
flat file data sources, connections
flat files, connections
flush command
flushdns parameter, Ipconfig utility
FMU (File Migration Utility) 2nd
Folder icon (Active Directory)
Folder Redirection 2nd 3rd
folders
auditing
Computers, objects
creating
encrypting
FTP Sites folder properties page
monitoring
My Documents, redirecting to home directories
NTFS, auditing
offline access
recovering
DFS
Ntbackup.exe
VSC
redirecting
roaming profiles
to home directories
to local user profiles
to network sharing
to root directories
to special paths
staging
SYSVOL, restoring
Users, objects
forcing replication
foreign DNS and Active Directory DNS, co-existing
forests
account/resource domains
Active Directory domain trees 2nd
cross-forest transitive trusts
cross-forest trusts 2nd
domain controllers
domain trusts
federated forests design model 2nd
functionality levels, configuring
Group Policies
inplace upgraded, new forests, compared
new inplace upgraded forests, compared
NT4 migration
security
single forest model
special-purpose domains
subdomains, shortcut trust
XML documents
FORFILES.exe utility
formats, files
formatting
disks
partitions
forms, printer management
forward lookup zones
forwarders
FPNW (File and Print Services for NetWare) 2nd
FQDN (fully qualified domain name) 2nd
frames, capturing (Netmon)
frameworks [See Windows .NET Framework.]
free pools
FREEDISK.exe utility
FrontPage 2003, SharePoint integration
FRS (File Replication Service) 2nd
event logging
monitoring
multimaster replication
pre-install directory
replication
staging folder
terminology
FRSDiag.exe
frssysvol test
FsmoCheck test
FSRM (File Server Resource Manager) 2nd
configuring user storage limits
creating
file screen templates
file screens
quota templates
storage reports
installing
Fsutil.exe, disk/volume monitoring
FTP (File Transfer Protocol)
Active Directory
authentication, securing
configuration settings
properties pages
security
services, installing and configuring
site properties
Sites Properties page
sites, creating
transfers, securing
users, isolating
FTP Site tab (FTP Sites folder properties page) 2nd
full mesh topology
full zone transfers 2nd
Fully Qualified Domain Name (FQDN) 2nd
functional levels (Active Directory)
mixed domain
upgrading
Windows .NET Interim mode (interim domain functional level)
Windows 2000 Native mode (native domain functional level)
Windows Server 2003 domain functional level
functionality levels, configuring forests
functionality, Windows Server 2003 (improvements)
functions
application servers
attribute flow


G

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

g parameter
Arp
Pathping command
GANTT charts
gateway parameter, Route command
Gateway Services for NetWare (GSNW)
GC/DCs (Global Catalog Domain Controllers)
GCs (global catalog servers)
generic cluster resources
geographic-based configuration groups (MOM)
geographical depth and breadth, Windows Server 2003 migration
geographical diversity of users, migration testing
geographical-based designs
GetObject method, users, creating
GETTYPE.exe utility
ghost domain controllers, retiring
GLBA (Gramm Leach Bliley Act) 2nd
global catalog
Active Directory 2nd
information, caching
media, creating
schema modifications
servers 2nd
synchronization
Global Catalog Domain Controllers (GC/DCs)
global catalog restores
global catalog servers (GCs)
global groups 2nd 3rd 4th
goals
business, identifying
migration processes
projects, design documents
technical, identifying
deployment team participants, defining
design team participants, defining
scope of work, defining
timeframes (implementation or migration), determining
GPMC (Group Policy Management Console) 2nd 3rd 4th
backups
copying
downloading
forests
Group Policies, searching
HTML reports
importing
restoring
RSoP 2nd
tables, migrating
WMI Filters, linking
GPmonitor.exe
GPOs (Group Policy Objects) [See also Group Policies; Group Policy Object Editor.]
creating
deleting
disabling
editing
Local Group Policy Object, editing
namespaces
naming conventions
Registry, auditing
unlinking
GPOTool.exe
GPresult.exe
GPupdate.exe
Gramm Leach Bliley Act (GLBA) 2nd
granular session control
grooming intervals, MOM databases
Group Account Migration Wizard 2nd
group designs, OUs
group management, MIIS
Group Policies
administrative templates
add-on
baseline Outlook preferences
customizing 2nd
delegates
managing
Outlook 2nd
Polices vs preferences
rights, assigning
automatic client configurations
backing up
Block Policy Inheritance 2nd
computer policies
configuration settings, disabling
configuring
copying
creating
cross-domain assignments
default domain policy
desktop application management
Enforcement feature
GPMC
Group Policy snap-in, configuring
importing
inheritance 2nd 3rd
installing
Link Enabled option
linking
loopback
managing
minimum
names
network clients real-life scenarios
administrator workstations
mobile users
power user support
remote users
security
workstation lock downs
network clients, managing
No Override option
ordering
orphaned, deleting
refresh intervals
restoring
rights
RSoP 2nd
searching
searching for orphaned script 2nd
security
slow links 2nd
snap-in namespaces
snap-ins, opening
software installations
system event auditing
Terminal Servers
Terminal Services security
tools
troubleshooting
user policies
viewing 2nd
Windows Server 2003 installations
WMI
Group Policy Management Console [See GPMC (Group Policy Management Console).]
Group Policy Object [See GPOs (Group Policy Objects).]
Group Policy Object Editor 2nd
Folder Redirection
folders, redirecting
opening
policies, viewing
Scripts (Logon/Logoff) extension
Scripts (Startup/Shutdown) extension
Group Policy snap-in, configuring
Group table window
groups
Active Directory 2nd
creating
distribution
domain functionality levels
domain local 2nd
forest user administration
global 2nd
machine local
managing
OUs (organizational units), comparing
populating
scopes
security
single domain user administration
types of
universal 2nd
cluster resource
clusters
creating
moving
configuration (MOM)
geographic-based
multiple
political
security-based
designs
best practices
business function-based
distribution groups
geographical-based
group naming standards
group nesting
model samples
universal distribution groups
universal groups
universal security groups
distribution groups
distribution, designs
domain local 2nd
global 2nd 3rd
local
machine local 2nd
mail-enabled groups
migrating ADMT v2.0 domain migration
naming standards
nesting
permissions, assigning
resource sharing
policies, OU designs
restricted
Group Policies
security
scopes
security
SID (Security ID)
structure designs
types of
universal 2nd 3rd
BDCs
caching 2nd
distribution
incremental membership replication
memberships, replicating
security
GSNW (Gateway Services for NetWare)


H

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

h parameter
DCDIAG
Pathping command
Tracert utility
handlers/worker processes (applications)
hard drives
failures
partitions, formatting
hard faults (memory)
hardware
allocating, compatibility testing
compatibility list Web site
configuring, compatibility testing
inventory documentation
MOM requirements
network, fault-tolerant systems
NT4 migration compatibility
NTDETECT.COM
SharePoint requirements
single server upgrade compatibility
verifying
Windows Server 2003 requirements
HARDWARE subkey (HKEY_LOCAL_MACHINE hive)
hardware-based RAID 2nd
HARDWARE/ACPI subkey (HARDWARE subkey)
HARDWARE/DESCRIPTION subkey (HARDWARE subkey)
HARDWARE/DEVICEMAP subkey (HARDWARE subkey)
HARDWARE/RESOURCEMAP subkey (HARDWARE subkey)
Health Insurance Portability and Accountability Act (HIPAA) 2nd
Heartbeats, clusters 2nd
help command
Heroix Web site
Hewlett-Packard Web site
hidden namespaces (DNS)
HIDS(host-based intrusion detection system)
hierarchies
DNS
text, OU structures
high-level business goals, identifying
high-level migration project plan
high-speed links, disabling compression
highly secure templates
HIPAA (Health Insurance Portability and Accountability Act) 2nd
history
DNS
WSUS
hives (Registry)
displaying
HKEY_CLASSES_ROOT 2nd
HKEY_CURRENT_CONFIG 2nd
HKEY_CURRENT_USER 2nd
HKEY_LOCAL_MACHINE
HARDWARE subkey
HARDWARE/ACPI subkey
HARDWARE/DESCRIPTION subkey
HARDWARE/DEVICEMAP subkey
HARDWARE/RESOURCEMAP subkey
SAM subkey
SECURITY subkey
SOFTWARE subkey
subkeys
SYSTEM subkey
HKEY_USERS 2nd
HKEY_CLASSES_ROOT hive 2nd
HKEY_CURRENT_CONFIG hive 2nd
HKEY_CURRENT_USER hive 2nd
HKEY_CURRENT_USER\Software\Classes alias
HKEY_LOCAL_MACHINE hive
HARDWARE subkey
HARDWARE/ACPI subkey
HARDWARE/DESCRIPTION subkey
HARDWARE/DEVICEMAP subkey
HARDWARE/RESOURCEMAP subkey
SAM subkey
SECURITY subkey
SOFTWARE subkey
subkeys
SYSTEM subkey
HKEY_USERS hive 2nd
home directories
Home Directory tab
Default Web Site Properties page
FTP Sites folder properties page
home users, access 2nd
HOST file, DNS troubleshooting
host records
host-based intrusion detection system (HIDS)
hosted applications, Terminal Services planning
hosts, Windows .NET Application Host
hotfixes
command-line parameters
consistency
deploying
SUS
Windows Update
Hotmail Web site
HTML reports, Group Policies
HTTP
compression settings
Http.sys
HTTP Headers tab (Default Web Site Properties page)
Http.sys
hub and spoke topology
hub-and-spoke replication design example


I

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

i parameter
DCDIAG 2nd
PING command
IAS (Internet Authentication Service)
ICMP (Internet Control Message Protocol)
icons, Folder (Active Directory)
Identity and Integration Feature Pack (IIFP) 2nd
Identity Management for Unix (IdMU)
identity management, MIIS 2nd
idle timeout, applications
IdMU(Identity Management for Unix)
IDs (intrusion detection system) 2nd
IE (Internet Explorer)
IETF (Internet Engineering Task Force)
IF parameter, Route command
IHVs (Independent Hardware Vendors)
IIFP (Identity and Integration Feature Pack) 2nd
IIS (Internet Information Server) 2nd
Active Directory security
applications
configuring and optimizing
CPU utilization
idle timeout
isolating and pooling
monitoring
options
performance
process recycling
queues
Web Gardens
metabase, backing up
recovering
snap-in, configuring IIS 6
IIS 6 (Internet Information Services 6)
Admin services
application monitoring
application pools
applications, handlers/worker processes
backup configuration settings
components (optional)
configuring
IIS snap-in
virtual directories
Web services, configuring
Web site properties, selecting
Web sites, creating
Web sites, selecting properties 2nd
designing
fault tolerance
requirements, determining
tier environments
FTP
properties pages
services, installing and configuring
sites, creating
users, isolating
Http.sys
improvements
Indexing Service
installing
logging
maintaining
managing
NNTP Service
planning
process recycling
scalability
security 2nd
auditing
authentication
FTP security
SSL certificates
Web service extensions, locking down
Windows .NET Server 2003
servers, requirements, determining
services administration window
SMTP Service
upgrading
WAS (Web Administration Services)
Web application server settings
Web Service Extensions
Web sites
worker process isolation mode
IIS logging
IIS Manager
IIS 6 metabases, backing up
virtual directories, creating
IIS metabases
image installations
images
desktop
updating
Windows XP deployment
deployment tools
desktop customization
desktop software, installing
errors
RIS customizations
tools 2nd
unattended installation
implementation timeframes
implementing
projects
Windows Server 2003
Import Template dialog box
imported pools
importing Group Policies 2nd
incremental universal group membership replication
incremental zone transfers 2nd
Independent Hardware Vendors (IHVs)
Indexing Service, IIS 6
information
dynamic, enabling or disabling
for structured design documents, organizing
information overload management, Windows Server 2003 migration
Information Systems Web site
infrastructure master (OM role)
inheritance, group policies 2nd 3rd
initial masters
inplace upgrades 2nd [See also rolling upgrades, cluster nodes.]
AD upgrade
backup domain controllers
BDC upgrade
Directory Services Restore Mode security
domain controller upgrades
domain member servers
forest functionality levels
starting
Windows 2000 to Windows Server 2003 migration
installation media (Windows XP)
installing
ADFS (Active Directory Federation Services)
ADMT 2nd
applications
Certificate Services 2nd
client access licenses
Cluster Service
first node 2nd
nodes, adding
pre-install checklist
desktop applications, manually
desktop software
DFS
DHCP
DNS, Configure Your Server Wizard
domains
encryption keys
FSRM
FTP services
Group Policy
IAS
IIS 6
IPv6
Media Encoder
Media Services
MIIS
.NET Passports
Netmon
Network Monitor
NLB clusters
password migration DLL
PMC (Print Management Component)
Producer
published applications
Quarantine Policy Check tool
Recovery Console
Remote Storage
RIS
RRAS 2nd
Service Pack updates
SFNW
SFU
SharePoint
SMTP Service
Software Installation Service (Group Policy)
software, group policies
Terminal Server
Terminal Services
Remote Desktop for Administration
Terminal Server mode
Windows 2003 R2 components
Windows Server 2003
administrator passwords
alternative methods
computer names 2nd
date and time
domain names
existing domains, joining
file backups
Group Policies
hardware requirements
images
information, gathering
IP addresses
languages
licensing modes
network settings
new installation
operating system
partitions, formatting
personalizing
product keys
server types
SMS
unattended 2nd
upgrade
workgroup names
Windows XP deployment tools
Windows XP, unattended
Windows XP/Windows 2000
WINS
WSUS
instances, SQL Server 2000 (SharePoint)
integrated Windows authentication
integrated zones, DNS
integrating
directories, networks
WINS & DNS
integrity, file systems maintenance
Inter-Site Topology Generator [See ISTG (Inter-Site Topology Generator).]
Interface group table window
interfaces [See also ADSI (Active Directory Service Interfaces).]
Network Monitor
SharePoint
synchronization, Producer
Windows Server 2003, customizing and programming
interim level
Interim mode (interim domain functional level) (Windows .NET)
Interix
internal namespaces 2nd
internal security audits 2nd
Internet
DNS (domain name system) namespaces
standards, Microsoft adoption
system activation
Internet addresses
dotted-decimal format
IPv4
IPv6
addresses
advantages
installing
migration
structure
Internet Authentication Service (IAS)
Internet Control Message Protocol (ICMP)
Internet Engineering Task Force (IETF)
Internet Explorer [See IE (Internet Explorer).]
Internet Explorer, Enhanced Security Configuration
Internet Information Server [See disaster recovery, IIS.]
Internet Information Server and Site Server
Internet Information Services [See disaster recovery, IIS.]
Internet Protocol Security [See IPSec security improvements.]
Internet Protocol version 4 (IPv4)
Internet Protocol version 6 [See IPv6 (Internet Protocol version 6).]
Internet Security and Acceleration (ISA) Server 2004
internetworks, VPN
interoperability
NetWare
FMU
GSNW
SFNW
UNIX [See components, SFU.]
Interrupts/sec counter
Intersite test
Intersite Topology Generator Algorithm (ISTG) 2nd
Interval parameter, Netstat
Intrasite Automatic Tunnel Addressing Protocol (ISATAP)
intrusion detection system (IDS)
INUSE.exe utility
inventory
applications
network systems
inventory sheets, applications
IP addresses 2nd
IP addresses window
IP filtering driver, RRAS
IP Multicast Forwarders, RRAS
IP multicast routing protocols, RRAS
IP replication
IP Router Manager, RRAS
IP routing table window
IP Security protocol (IPSec)
IP Unicast Forwarders, RRAS
IPconfig
IPCONFIG program, DNS troubleshooting
Ipfltdrv.sys
Iprip2.dll
Iprtmgr.dll
IPSec (Internet Protocol Security) 2nd 3rd
advantages
functions
NAT-T
policies
Security Monitor
testing
VPNs
IPSec (IP Security) policies
IPSec NAT Transversal
IPSec security improvements
IPv4 (Internet Protocol version 4)
IPv6 (Internet Protocol version 6) 2nd
addresses
advantages
installing
migration
structure
IPX filtering driver, RRAS
IPX forwarder drivers, RRAS
IPX parameters window
IPX Router Manager
IPX routing table window
IPX service table window
ipxrip.dll
Ipxrtmgr.dll
ipxsap.dll
ISA (Internet Security and Acceleration) Server 2004
ISAPI Filters tab (Default Web Site Properties page)
ISATAP (Intrasite Automatic Tunnel Addressing Protocol)
ISDN records
island problem (DNS)
isolating
applications
failures
FTP users
issue-specific security policies
issues lists (SharePoint)
ISTG (Inter-Site Topology Generator) 2nd
IT Personnel forms
iterative queries
IXFR (Incremental Zone Transfers) 2nd
IXFR Request Received (DNS zone transfer counter)
IXFR Request Sent (DNS zone transfer counter)
IXFR Response Received (DNS zone transfer counter)
IXFR Success Received (DNS zone transfer counter)
IXFR Success Sent (DNS zone transfer counter)


J

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

j parameter
PING command
Tracert utility
jetpack program
junction points


K

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

k parameter, PING command
KCC (Knowledge Consistency Checker)
kccevent test
Kerberos 2nd
Kernel Time
KEY records
keys (Registry)
adding in Registry
backing up
binary values
deleting in Registry
DWORD values
expandable string values
multi-string values
permissions, setting
restoring
saving
string values
subkeys
values
Kids .NET Passport
Kids Privacy Statement (.NET Passport)
Knowledge Consistency Checker (KCC)
knowledge management, documentation
KnowsOfRoleHolders test


L

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

l command-line parameter
l parameter
NetDiag
PING command
L2TP
advantages
VPNs
L2TP (Layer 2 Tunneling Protocol) 2nd
L2TP/IPSec (L2TP IP Security protocol)
L2TP/IPSec connections, authentication protocols
lab-testing compatibility
ACT
applications, installing
hardware allocation/configuration
upgrades
Windows Server 2003 allocation/configuration
labs
building
testing process results
LAN users, Terminal Services
languages, operating systems
Last Known Good Configuration
last node rolling upgrade
latency, replication 2nd 3rd
Layer 2 Tunneling Protocol [See L2TP.]
layers, security
layouts, Windows NT resource domains (mapping OU designs)
LDAP (Lightweight Directory Access Protocol) 2nd 3rd
Ldifde.exe
libraries
document, SharePoint
Explorer View
picture, SharePoint
License servers (TS)
activating
client access licenses
licensing types
licenses
client access
managing
Terminal Services
licensing
.NET Passport
AD sites, configuring
Licensing applet
licensing modes
licensing servers, AD sites
Licensing snap-in
Lightweight Directory Access Protocol [See LDAP (Lightweight Directory Access Protocol).]
lingering objects, deleting
Link Enabled option, group policies
Link state database window
linked-value replication
linking
group policies
WMI Filters
links [See also site link bridgeheads, Active Directory replication.]
AD sites 2nd
bridgeheads
bridging
creating
replication schedules
replication topology
DFS 2nd
GPOs (Group Policy Objects), unlinking
high-speed, disabling compression
HKEY_CLASSES_ROOT hive
HKEY_CURRENT_CONFIG hive
HKEY_CURRENT_USER hive
SharePoint list of
slow, group policies
WAN, configuration groups
lists, SharePoint
live broadcasts
initiating
pulling content
pushing content
LMHOSTS file
load balancing
load testing Media Services
loading Database objects
local disks, backing up cluster nodes
local drive redirection
local group memberships, checking script
Local Group Policy Object, editing
local groups
local policies
Registry, auditing
security
local printers, adding
local quorum resources
local resource redirections
local security policies, viewing
Local Security Policy snap-in
local time zones
redirecting
supporting
local user profiles 2nd
locations
AD databases
Registry
locking down
Web service extensions
workstations
log files, saving
log-file format (.evt)
log-parsing tools
logarchive.ini
Logarchive.vbs
logging
authentication and accounting
event
IIS 6
Logical Disk object
logins
restricting
smartcards
Windows Server 2003
logon.bat files, adding as startup scripts
logon/logoff events, tracking 2nd
logs
application 2nd
archive event, checking 2nd
CLFS
counter
Directory Service
DNS Server
event
analyzing
archiving
customizing
FRS
retrieving 2nd
security
File Replication Service
properties
reviewing after upgrades
security 2nd
Security Log
system
trace
viewing remote servers
lookups, WINS DNS
loopback, group policies
looping videos


M

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

m command-line parameter
machine local groups 2nd
MachineAccount test
Mail Exchanger records (MX)
mail-enabled groups
mailbox records (MB)
maintenance
AD databases
cluster nodes
DFS, offline targets
DHCP 2nd
DNS
documentation
file system integrity
IIS 6
NLB nodes
servers
tasks
Windows .NET Server 2003
daily
monthly
quarterly
weekly 2nd
Windows Server 2003
daily 2nd
MMC 3.0
monthly 2nd
quarterly
weekly
WINS 2nd
Majority Node Set (MNS)
Manage Your Server Wizard, installing IIS6
management
group, MIIS
identity, MIIS 2nd
Out-of-Band Management
Management Agents (MAs)
management applications, RRAS
management improvements, Windows .NET Server 2002
management packs
application management
MOM resource kits
networks
standard
XMPs
management rights, Group Policies
management wizards
management-level reporting, performance documentation
managers
connection, RRAS
IIS Manager, creating virtual directories
Task Manager
managing
accounts, monitoring
AD groups
client software installations
Cluster Service
Cluster Administrator
Cluster Automation Server
cluster groups, creating
cluster groups, moving
Cluster.exe
failbacks
failovers
node maintenance
nodes, deleting
passwords
resources, creating
testing clusters
desktop applications
Group Policy
manual installations
third-party packaging software
disks
documents, SharePoint
file shares
Group Policies
application order
backups
copying
importing
inheritance
management rights, delegating
policies
preferences
refresh intervals
restoring
RSoP
security templates
Group Policy configurations
IIS 6
information overload, Windows Server 2003 migration
IP routing
IPX routing
knowledge management, documentation
licenses
media pools
media, Remote Storage
network clients, Group Policy [See Group Policies, network clients, managing.]
NLB clusters
backups
deleting clusters
deleting nodes
maintenance
patches
printers
adding print servers
adding shared printers
configuring PMC
general printer administration
installing PMC
Registry size
Registry, cleaning
servers
domain controllers
file servers
print servers
remotely
scripts
server roles
terminal servers
Web servers
shadow copies
SharePoint discussions
storage [See storage.]
systems, MOM
users [See policies, users; user management scripts.]
volumes, NTFS quotas
Windows XP desktops 2nd
Windows XP installation media
workstations, scripts
mandatory user profiles
manual failover cluster testing
manual server recovery
mapping OU designs
Mappings window
MAs (Management Agents)
mask parameter, Route command
master account lists
masters
domain naming (OM role)
infrastructure (OM role)
multi-master replication (Active Directory)
RID (Relative ID) (OM role)
schema (OM role)
MB (mailbox) records
MBSA (Microsoft Baseline Security Analyzer)
Mean Time Between Failures (MTBF)
Mean Time to Repair (MTTR)
media
creating for global catalog
global catalog servers, building from
managing Remote Storage
media pools
removable media databases, recovering
removable media, Remote Storage configuration
media content
bit rates
distribution methods
pushing/pulling
screens, capturing
Media Encoder
captured broadcasts
installing
live broadcasts
requirements
screen content, capturing
video file conversions
Media Load Simulator tool
media servers
Media Services [See also Media Encoder.]
captured broadcasts
configuring
installing
live broadcasts
load testing
performance
playlist broadcasting
Producer
real-time live broadcasts
single video broadcasts
system requirements
video directories
media sessions, capturing
media-based GC/DC replication
media-integrated presentation files
meeting workspaces, SharePoint
members of teams, roles and responsibilities
memberships
incremental universal group membership replication
local group, checking
universal groups, replicating
memory
debugging
hard faults
soft faults
system, monitoring
Memory Monitor utility
menus, Favorites (Registry Editor)
Messages tab (FTP Sites folder properties page)
messaging servers, monitoring
metabases
editing
IIS 6, backing up
IIS, backing up
metadirectories
defined
MIIS
account provisioning
group management
identity management 2nd
IIFP
installing
management agents
overview
SQL Server database
terminology
Web site
MMS
Metaverse Namespaces (MVs)
metric baselines, establishing
METRIÇ parameter, Route command
Microsoft Baseline Security Analyzer (MBSA)
Microsoft Cluster Service (MSCS) [See Cluster Service.]
Microsoft Directory Synchronization Services (MSDSS) 2nd
Microsoft Identity Integration Server [See MIIS (Microsoft Identity Integration Server).]
Microsoft Management Console [See MMC (Microsoft Management Console).]
Microsoft Metadirectory Services (MMS)
Microsoft Office 2003
Microsoft Operations Manager [See MOM (Microsoft Operations Manager).]
Microsoft Point-to-Point Encryption (MPPE)
Microsoft Producer [See Producer.]
Microsoft Security Notification Service
Microsoft Statement of Policy
Microsoft Word
Microsoft, Internet standards, adopting
mid-level compatibility testing
Migrate Associated User Groups option (ADMT)
migrating [See also ADMT (Active Directory Migration Tool), domain migration, domain accounts, migrating.]
computer accounts 2nd
domain accounts, AD
domain controllers
from Windows 2000 to Windows Server 2003
from Windows NT4 to Windows Server 2003
high-level migration project plan
IPv6
NT4 groups into AD
NT4 to Windows Server 2003 forest
account/resource domains
domain installation
domain trusts
security
NT4 to Windows Server 2003, inplace upgrade
security
service accounts into AD
tables, Group Policies
user accounts, ADMT v2.0 domain migration
Windows 2000 AD forest
AD-Integrated DNS zones, moving
domain controller migration
domain controller upgrade
functional levels, upgrading
ghost domain controllers
OM roles
replacing domain controllers
retiring domain controllers
schema upgrade
Windows 2000 AD forest Mixed-Mode Domain Redirect
existing forest, retiring
NT PDC promotion
OM roles
production domain controllers
re-establishing domain controllers
requirements
secondary temporary server
temporary domain controllers 2nd
Windows 2000 to Windows Server 2003
application readiness
inplace upgrade
migration objectives
new hardware migration
options
phases
quick vs. slow approach
recovery process
single server upgrade
standalone server upgrade
Windows Server 2003 2nd
ADMT (Active Directory Migration Tool)
approach to defining steps and milestones
budget estimates 2nd
business goals and objectives, identifying
collaborative design decisions
design agreements
design decisions
design phase
discovery phase
domains, renaming
end state (technology configurations)
end-user satisfaction, verifying
environment, supporting
executive summaries 2nd
GANTT charts
geographical depth and breadth
information overload management
lab testing process results
labs, building
migration documents, creating
migration planning phase
migration process goals and objectives
migration/implementation phase
network background information
pilot phase
pilot results, documenting
pilot users, application usage requirements
pilot users, geographical diversity
pilot users, quantity of
pilot users, role requirements
problem solving
project goals and objectives
project plans
project scope
prototype phase
solutions, implementation approach
speed and risk, comparing
structured design documents, organizing information
table of contents (sample) 2nd
team members' roles and responsibilities
technical goals and objectives, identifying
to Windows 2000
to Windows NT4
migration documents 2nd
approach to defining steps and milestones
budget estimates
checklists
creating
desktop
executive summaries
migration process goals and objectives
project plans 2nd
servers
table of contents (sample)
team members' roles and responsibilities
test plans
users
migration objectives, Windows 2000 to Windows Server 2003 migration
migration paths
domains, consolidating
existing domains to Windows Server 2003 forest
inplace upgrades
selecting
migration planning phase, Windows Server 2003 migration
approach to defining steps and milestones
budget estimates
executive summaries
GANTT charts
migration documents, creating
migration process goals and objectives
project plans
speed and risk, comparing
table of contents (sample)
team members' roles and responsibilities
migration processes, goals and objectives
migration timeframes, determining
migration/implementation phase, Windows Server 2003 migration
MIIS (Microsoft Identity Integration Server)
account provisioning
group management
identity management 2nd
IIFP
installing
management agents
overview
SQL Server database
terminology
Web site
milestones of migration projects, defining
MiniSetups
mirrored volumes 2nd
mixed administration model
mixed domain functional level (Active Directory)
Mixed mode (Windows 2000 Active Directory)
Mixed-Mode Domain Redirect (AD forest upgrades)
existing forest, retiring
NT PDC promotion
OM roles
production domain controllers
re-establishing domain controllers
requirements
secondary temporary server
temporary domain controllers
MMC (Microsoft Management Console) 2nd 3rd
Group Policy Object Editor, opening
snap-in namespaces (Group Policy)
MMS (Microsoft Metadirectory Services)
MNS (Majority Node Set)
MNS cluster
Cluster Service configuration
example
mobile devices, .NET Passport
mobile users, network client Group Policy example
models
administrative
federated forests design
groups
multiple domain
OUs
peer-root domain
placeholder domain
single domain
single forest
modes
authentication (Active Directory)
Native mode domains, universal groups
Windows .NET Interim (interim domain functional level)
Windows 2000 Mixed
Windows 2000 Native (native domain functional level)
worker process isolation (IIS 6)
modes of operation (Terminal Services)
MOM (Microsoft Operations Manager) 2nd 3rd 4th
administration
agents 2nd
alerts
architecture
backing up
capacity limits
configuration groups
geographic-based
multiple
political
security-based
configuring
consolidator
D-DCAM servers
DAS
data storage
data, archiving
database servers
databases, sizing
DCAM servers
events, processing
failovers
grooming intervals
hardware requirements
management packs
MSDE database
multiple server configuration
overview
performance data, processing
performance monitoring
Prerequisite Checker
redundancy
reporting
responses
scalability
security
service accounts
single server configuration
software requirements
system management
tools
Web console
MOM DTS
MOM-to-Tivoli connector
monitoring
account logon events
account management
applications
IIS 6
Task manager
database servers
DFS status
directory service access
disaster recovery documentation
disks
domain controllers
Event Viewer
file servers
files
folders
FRS
logon events
messaging servers
MOM performance
networks 2nd [See also consoles, Netmon.]
object access
performance
baselines [See baselines.]
objects
overhead
Task manager
tools
policy changes
print servers
printers
privilege use
process tracking
processes, Task manager
remote
resource access 2nd
system events
systems
CLFS
Performance Logs and Alerts utility
performance monitoring tools
System Monitor utility
tools
trace logs
Terminal Services
user activity, Task manager
volumes
Web servers
monitoring tools
monitors, Network Monitor
monthly maintenance
MPPE (Microsoft Point-to-Point Encryption)
Mprdim.dll
MS-CHAP protocol
MSCS (Microsoft Cluster Service) [See Cluster Service.]
msdcs subdomain, DNS
MSDE database, MOM
MSDSS (Microsoft Directory Synchronization Services) 2nd
MSICUU (Windows Installer Cleanup Utility)
MSIZAP.EXE (Windows Installer Zapper)
MTBF (Mean Time Between Failures)
MTTR (Mean Time to Repair)
multi-master replication (Active Directory)
multi-string values
Multicast boundaries window
multicast delivery, unicast delivery (compared)
Multicast Group Manager, RRAS
multicast imaging software
Multicast mode (clusters)
Multicast scopes, DHCP
Multicast statistics window
multimaster replication 2nd
multipath I/O, shared storage
multiple configuration groups (MOM)
multiple domain model
multiple host mode (port filtering)
multiple RRs
multiple server MOM configuration
multiple-site designs
multivalued attribute replication
MVs (Metaverse Namespaces)
MX (Mail Exchanger) records
My Documents folders, redirecting to home directories
My Site (SharePoint)


N

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

n command-line parameter
n parameter
DCDIAG 2nd
Netstat
Pathping command
PING command
name resolution 2nd
Name Server records (NS)
names
computers 2nd
DDNS (Dynamic DNS)
distinguished (Active Directory)
DNS (domain name system)
domain accounts
domain naming master (OM role)
domain rename tool
domains 2nd 3rd
global groups
GPOs
Group Policies 2nd
groups, standards
publishing points 2nd
relative distinguished (Active Directory)
UPN (user principal name)
workgroups
namespaces
DNS 2nd
external
GPOs (General Policy Objects), security settings
internal
private
public
published
snap-in (Group Policy)
NAT (Network Address Translation) 2nd 3rd
NAT Traversal (NAT-T)
remote access
remote access clients
National Institute of Standards and Technologies (NIST) Web site
National Security Agency (NSA) Web site
Native mode (native domain functional level) (Windows 2000)
Native mode domains, universal groups
NBT Connection: Bytes Total/sec (network traffic counter)
NBT Redirector: Bytes Total/sec (network traffic counter)
NBT Server: Bytes Total/sec (network traffic counter)
NCSecDesc test
Neighbors (OSPF) window
Neighbors (RIP) window
nested control delegation
nested groups, sharing resources
nesting
groups 2nd
OU (organizational unit) structures
.NET Framework
.NET Passports
policies
.NET Passport authentication
.NET Passports
accounts
benefits
compliance criteria
cookies
encryption keys
installing
Kids
Kids Privacy Statement
licensing
mobile devices
Passport Manager Administration program
PREP IDs 2nd
Privacy Policy
security
service agreements
Services agreement
Web site
Web-based application integration
.NET Services Manager Web site
NetBIOS, WINS
NetDiag (Network Connectivity Tester)
NetIQ Corporation Web site
NetLogons test
Netmon (Network Monitor) 2nd
capacity analysis
Capture Filter
console
frames, capturing
installing 2nd
interface
Session pane
Station Statistics pane
Netsh
command-line options
commands
RRAS 2nd
Netstat (Network Statistics)
NetWare
GSNW
interoperability
SFNW
FMU
FPNW
installing
MSDSS
Network Address Translation (NAT) 2nd 3rd
network cards, NLB clusters
network clients
Group Policy management 2nd
application order
backups
block policy inheritance
client software installations
client updates
copying
cross-domain assignments
deployment
disabling
folder redirection
importing
inheritance
management rights, delegating
names
no override
policies
preferences
push successes
refresh intervals
restoring
RSoP
security templates
simplicity
Group Policy real-life scenarios
administrator workstations
mobile users
power user support
remote users
security
workstation lock downs
network configuration documentation 2nd
as-built document
network devices
WAN
Network Connectivity Tester (NetDiag)
network devices
network infrastructure security policies
address-based restrictions
firewalls
network access
Network Interface Cards (NICs)
network intrusion detection system (NIDS)
Network Load Balancing [See Terminal Services, fault tolerance, network load balancing.]
Network Monitor [See consoles, Netmon.]
Network News Transport Protocol (NNTP)
network operating system (NOS) [See also Windows Server 2003.]
network outages
Network Statistics (Netstat)
network subsystems, monitoring
network systems, inventory
Networking tab (Task Manager window)
networking, Terminal Server requirements
networks
access, security
addressing
background information, design documents
directory integration
enterprise
hardware, fault-tolerant systems
management packs
monitoring 2nd [See also consoles, Netmon.]
name resolution
NBT Connection: Bytes Total/sec (network traffic counter)
NBT Redirector: Bytes Total/sec (network traffic counter)
NBT Server: Bytes Total/sec (network traffic counter)
NOS (network operating system)
resource distribution, viewing
security, risks
services, new features
settings
traffic, monitoring
virtual private [See security, VPNs.]
wireless policies, security
wireless, security
new features
DHCP
Windows Server 2003
Active Directory schema objects, deleting
configuration wizards
dragging and dropping
functionality improvements
global catalog information, caching
global catalog synchronization
high-speed links, disabling compression
IETF security standards, supporting
interface, customizing and programming
IPv6 standard, supporting
management wizards
performance improvements
security improvements
setup wizards
standards, supporting
tasks, simplifying
visual changes
XML Web Services, supporting
WINS
new hardware migration, Windows 2000 to Windows Server 2003 migration
new installation, Windows Server 2003 requirements
New Remote Access Policy Wizard
New Root Wizard
New Server Cluster Wizard
New Technology File System [See NTFS (New Technology File System).]
New Trust Wizard
New Volume Wizard
NFS
Client
SFU
NICs (Network Interface Cards)
NIDS (network intrusion detection system)
NIST (National Institute of Standards and Technologies) Web site
NISusers, adding to Active Directory
NLB (Network Load Balancing) 2nd
NLB clusters
backing up
creating clusters
deleting clusters
deleting nodes
filtering modes
installing
maintenance
network cards
nodes, adding
operation modes
port rules
switch flooding
NLB Manager, clusters, creating
NNTP (Network News Transport Protocol) Service
No Override option, Group Policies
node network failures, clusters
nodes
adding
clusters
NLB clusters
clusters
backing up
deleting
local disks, backing up
maintenance
restoring after cluster failure
system state, backing up
upgrading
failed
evicting/rebuilding
restoring
first, installing
MNS
NLB clusters
backing up
deleting
maintenance
single
restoring when server fails
restoring when service fails
non-Microsoft DNS implementations
non-Microsoft Kerberos realms
nonauthoritative restores
NOS (network operating system)
NS (Name Server) records
NSA (National Security Agency) Web site
Nslookup 2nd
NT [See Windows NT 4.]
NT File System [See NTFS (New Technology File System).]
NT LAN Manager (NTLM)
NT PDC, promoting
NT4 [See Windows NT 4.]
NTBACKUP [See Backup utility.]
NTDETECT.COM (hardware information)
NTDSUTIL
Active Directory
OM roles
NTFS (New Technology File System) 2nd 3rd
NTFS folders, auditing
NTFS permissions, root targets/link targets
NTFS volumes, quotas
NTLM (NT LAN Manager), Active Directory
Nwlnkflt.sys
Nwlnkfwd.sys


O

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

o command-line parameter
o parameter, Netstat
object access, monitoring
object identifiers (OIDs)
objectives
business, identifying
migration processes
projects, design documents
technical, identifying
deployment team participants, defining
design team participants, defining
scope of work, defining
timeframes (implementation or migration), determining
objects [See also GPOs (Group Policy Objects).]
Active Directory
OUs
Scripting
Active Directory schema 2nd
attributes
Computers folders
connection, replication
Container class
Database, loading
FileReplicaConn
FileReplicaSet
Local Group Policy Object, editing
Logical Disk
performance
performance monitoring
Physical Disk
properties
removing
Users folders
ObjectsReplicated test
Office 2003, SharePoint integration
offline command
offline files
Offline Files Wizard
offline folder access
OIDs (object identifiers)
OM (Operation Master) 2nd 3rd
on-demand publishing points, playlists
on-demand publishing, broadcast publishing (compared)
one-way cross-forest trust
online backups, open files
online command
open files, online backups
opening
Group Policy Object Editor
Group Policy snap-ins
Openview Web site
operating systems [See also Windows Server 2003.]
administrator passwords
backing up
computer names
configuring
date and time
existing domains, joining
languages
licensing modes
network settings
NOS (network operating system)
NT4 migration requirements
partitions, formatting
personalizing
product keys
Operation Master (OM) 2nd
operation modes, NLB clusters
optimizing [See also performance optimization, bottlenecks.]
applications
DFS
options, Windows 2000 to Windows Server 2003 migration
ordering group policies
organizational units [See OUs (organizational units).]
organizing
information for structured design documents
security policies
Originating Writes, Active Directory replication
orphan group policies, deleting
OSPF routing protocol
Ospf.dll
OUs (organizational units) 2nd 3rd
Active Directory 2nd
administering, delegating
ADMT v2.0 domain migration
designs
business function-based designs
domain designs
flexibility
geographical-based designs
group policies
mapping
model samples
domain trusts, replacing
domains, comparing
group designs
and groups, comparing
network resource distribution, viewing
structure
nesting
text hierarchy
structure design
Windows .NET Server 2003 single domain
Out-of-Band Management
OutboundSecureChannels test
Outlk11.adm template
Outlook
administrative template
clients, look and feel
Group Policy settings 2nd
Web options
Outlook clients, policy options
overlapping recycling


P

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

p parameter
DCDIAG
Pathping command
P parameter, Netstat
Packet Internet Groper [See PING.]
Pages/sec counter
parameters
4
PING command
Tracert utility
6
PING command
Tracert utility
a
Arp
DCDiag 2nd
Netsat
PING command
add, Route command
all, Ipconfig utility
an, Netsat
c, DCDiag 2nd
change, Route command
ComputerToFind, Nslookup
d
Arp
NetDiag
Tracert utility
DCAccountEnum, NetDiag
DCDIAG
debug, NetDiag
Delete, Route command
destination, Route command
displaydns, Ipconfig utility
e
DCDiag 2nd
Netsat
f
DCDiag 2nd
PING command
Route command
ferr, DCDiag 2nd
fix
DCDiag 2nd
NetDiag
flushdns, Ipconfig utility
g
Arp
Pathping command
gateway, Route command
h
DCDIAG
Pathping command
Tracert utility
i
DCDIAG
PING command
I, DCDiag
IF, Route command
Interval, Netsat
j
PING command
Tracert utility
k, PING command
l
NetDiag
PING command
mask, Route command
METRIÇ, Route command
n
DCDiag 2nd
Netsat
Pathping command
PING command
o, Netsat
p
DCDIAG
Pathping command
Route command
P, Netsat
Pathping command
PING command
Print, Route command
q
DCDiag 2nd
NetDiag
Pathping command
R
Pathping command
Tracert utility
r
Netsat
PING command
registerdns, Ipconfig utility
release, Ipconfig utility
renew, Ipconfig utility
Route command
S
PING command
Tracert utility
s
Arp
DCDiag 2nd
Netsat
Server, Nslookup
setclassid, Ipconfig utility
showclassid, Ipconfig utility
skip
DCDiag 2nd
NetDiag
Subcommand, Nslookup
T, Pathping command
t, PING command
TargetName, PING command
test
DCDiag 2nd
NetDiag
u, DCDiag 2nd
v
DCDiag 2nd
NetDiag
PING command
w, PING command
partial authoritative restores
participating site cookies
partitions
of applications, AD-integrated DNS zones
basic
formatting
partners (replication)
passive screens
Passport (..NET)
accounts
benefits
compliance criteria
cookies
encryption keys
installing
Kids
Kids Privacy Statement
licensing
mobile devices
.NET Passport authentication
Passport Manager Administration program
policies
PREP IDs
Privacy Policy
security 2nd
service agreements
Services agreement
Web site
Passport Manager Administration program
password keys, ADMT v2.0 domain migration
password migration DLL, installing
passwords
AD Restore mode
administrator
changing
configuring
Cluster Service accounts
screen savers
synchronizing SFU
trusts
patch management
automating
Windows Automatic Update
patches [See also updates.]
consistency
service, compatibility
WSS servers
Pathping
paths
migration
domains, consolidating
existing domains to Windows Server 2003 forest
inplace upgrades
selecting
root, folders, creating
special, folders, redirecting
PATROL Web site
PDC Emulator (OM role)
peer-root domain model
real-world design example
selecting
Per Device licensing mode
Per Server licensing mode
per-user class registration
PerfMan Web site
performance [See also performance optimization; system performance.]
applications
baselines
Media Services
monitoring
MOM
objects
overhead
Task Manager
tools
Terminal Services
Windows Server 2003 improvements
Performance Console
capacity analysis
disk/volume monitoring
Performance Logs and Alerts
startup screen
System Monitor
trace logs
performance counters
AD (Active Directory)
DC (domain controller)
DNS (Domain Name Service)
performance data, processing MOM
performance documentation
performance improvements of Windows Server 2003
Performance Logs and Alerts utility
Performance Monitor 2nd
performance objects
performance optimization [See also performance; system performance.]
AXFR Request Received (DNS zone transfer counter)
AXFR Request Sent (DNS zone transfer counter)
AXFR Response Received (DNS zone transfer counter)
AXFR Success Received (DNS zone transfer counter)
AXFR Success Sent (DNS zone transfer counter)
bottlenecks
Cache % Hit (Active Directory performance counter)
Cache Page Fault Stalls/sec (Active Directory performance counter)
Cache Page Faults/sec (Active Directory performance counter)
Cache Size (Active Directory performance counter)
DC (domain controller)
Dynamic Update Received/Sec (DNS performance counter)
IXFR Request Received (DNS zone transfer counter)
IXFR Request Sent (DNS zone transfer counter)
IXFR Response Received (DNS zone transfer counter)
IXFR Success Received (DNS zone transfer counter)
IXFR Success Sent (DNS zone transfer counter)
patch management
Recursive Queries/Sec (DNS performance counter)
Recursive Query Failure/Sec (DNS performance counter)
Secure Update Received/Sec/Sec (DNS performance counter)
server roles
SPA 2.0
TCP Query Received/Sec (DNS performance counter)
TCP Response Sent/Sec (DNS performance counter)
Terminal Services
Total Query Received/Sec (DNS performance counter)
Total Response Sent/Sec (DNS performance counter)
UDP Query Received/Sec (DNS performance counter)
UDP Response Sent/Sec (DNS performance counter)
WSRM
Performance tab (Default Web Site Properties page)
Performance tab (Task Manager window)
permissions
ADMT v2.0 domain migration
assigning to nested groups
delegate, selecting
file shares
keys, setting
NTFS, root targets/link targets
Registry, configuring
security groups, sharing
security, setting
personal sites, SharePoint
personalizing
operating systems
SharePoint
phases, Windows 2000 to Windows Server 2003 migration [See also design phase, Windows Server 2003 migration; discovery phase, Windows Server 2003 migration; migration planning phase, Windows Server 2003 migration; migration/implementation phase, Windows Server 2003 migration; pilot phase, Windows Server 2003 migration; prototype phase.]
Phone Book Administrator
Phone Book Service
physical access enterprise-level security
Physical Disk object
physical security
access, restricting
administrative access
firewalls
logins, restricting
MOM
smartcards
wire
physical site disasters
picture libraries, SharePoint
pilot phase, Windows Server 2003 migration
pilot results, documenting
pilot users
problem solving
pilots, projects
PING
PKI (Public Key Infrastructure) 2nd
Non-Microsoft Kerberos realms
smartcards
placeholder domain model
placement
AD global catalog 2nd
Terminal Servers
planning
compatibility testing
DFS replication
disaster recovery
documenting
network outages
physical site disasters
power outages
server failures
domain DFS
IIS 6
projects
Remote Desktop for Administration
RIS deployments
site failures
Terminal Server mode
Terminal Services
plans, projects
playlist broadcasting
broadcast publishing points
configuring
on-demand publishing points
playlists
starting
wrapper, creating
Plug and Play APIs, Registry
PMC (Print Management Component) 2nd
adding
print servers
printers as network shared resources
configuring
general printer administration
installing
Pocket MOM
Point of Presence entries (POPs)
Point-to-Point Protocol over Ethernet (PPoE) Dial-On-Demand
Point-to-Point Tunneling Protocol [See PPTP (Point-to-Point Tunneling Protocol).]
Pointer records (PTR)
points junction
points of failure, disaster recovery environment
points, publishing
delivery methods
names 2nd
single video broadcasts
summary
policies [See also GPOs (Group Policy Objects).]
.NET Passport
accounts, security
applied policies, viewing
auditing
changes, monitoring
computer
cross-domain assignments, group policies
default domain
documents
domains, ADMT v2.0 domain migration
Group Policies [See Group Policies.]
IPSec (IP Security) 2nd
local
Registry, editing
security
local security, viewing
preferences, compared
public key, security
Read and Apply Group Policy, security properties
security
administrative controls
application-level
desktop
education
enforcing
enterprise
enterprise-level
issue-specific
network infrastructure 2nd
organizing
procedures and checklists
system-level
technical controls
toolbox
software restriction, security
system usage
users 2nd
Group, creating
viewing
wireless networks, security
policy baselines, establishing
political configuration groups (MOM)
pooling applications
pools
application
media
popd command
POPs (Point of Presence) entries
populating AD groups
port rules filtering modes, NLB clusters
port rules, NLB clusters
Portal Server (SharePoint)
ports, configuring RDP
post-maintenance tasks (cluster nodes)
power outages
power users, supporting
PowerCfg.exe utility
PowerPoint presentations [See presentations.]
PPoE Dial-On-Demand (Point-to-Point Protocol over Ethernet)
PPTP (Point-to-Point Tunneling Protocol) 2nd
advantages
VPNs
PPTP connections, authentication
pre-boot execution (PXE) 2nd
pre-install checklist (Cluster Service)
pre-install directory
pre-installation, SharePoint
pre-maintenance tasks (cluster nodes)
predecessors, DHCP
preferences
baseline Outlook
Group Policies
policies, compared
PREP IDs 2nd
preparations, unattended installations
preparing
compatibility testing
NT4 to Windows Server 2003 migration [See Windows Server 2003, Windows NT4, migrating to.]
Windows 2003 R2 component installation
Prerequisite Checker (MOM)
prerequisites
domains, renaming
SFU
presence menus, SharePoint
presentations
audio
media-integrated
prestaging DFS replicas
preventing remote access
primary zones
Print Management Component [See PMC (Print Management Component).]
Print Management utility 2nd
Print parameter, Route command
print servers 2nd
adding to PMC (Print Management Component)
monitoring
printer drivers, updating
printer filters, creating custom
printers
domain, finding script
management
adding print servers
adding shared printers
configuring PMC
general printer administration
installing PMC
monitoring
queue redundancies
redirecting
prioritizing environments
Privacy Policy (.NET Passport)
private keys 2nd
private namespaces
privilege use, monitoring
problems, solving pilot phase of migration process
procedural documents
procedure baselines, establishing
procedures, security policies
process recycling (IIS 6)
process tracking, monitoring
processes
handlers/worker (applications)
monitoring Task Manager
running on systems
Processes tab (Task Manager window)
processing events and performance, MOM
processors, analyzing usage
Producer
installing
media-integrated presentation files, creating
media-integrated presentation files, publishing
synchronization interface
product keys
production domain controllers, demoting
profile cookies
<SecurityID> profile, HKEY_USERS hive
<SecurityID_Classes> profile, HKEY_USERS hive
ProfilePath attribute
profiles
.DEFAULT, HKEY_USERS hive
CM
creating
launching
local users, redirecting folders
<SecurityID>, HKEY_USERS hive
<SecurityID_Classes>, HKEY_USERS hive
roaming redirected folders
roaming users, creating
run, management agents
user
All Users
copying
default
HKEY_USERS hive
local
mandatory
roaming
template
temporary
types 2nd
programming Windows Server 2003 interface
programs
antivirus
DNSCMD, DNS troubleshooting
IPCONFIG, DNS troubleshooting
jetpack
Netsh
NSLOOKUP, DNS troubleshooting
Passport Manager Administration
TRACERT, DNS troubleshooting
project scope, Windows Server 2003 migration
projects
design
discovery
goals and objectives, design documents
implementation
migration, defining steps and milestones
pilots
plans 2nd
prototypes
training
properties
category properties
computer, logs
date, logs
event, logs
events
FTP sites
logs
object
Read and Apply Group Policy security
source, logs
time, logs
type, logs
user, logs
Web sites, selecting
properties pages
FTP
virtual directories
property version numbers, replication
protecting Registry
auditing
event logs, analyzing
key permissions, setting
remote access, preventing
Security Log, analyzing
security permissions, setting
prototype phase
compatibility testing
Windows Server 2003 migration
prototype testing phase project plan
prototypes, projects
provisioning accounts, MIIS
PTR (Pointer) records
Public Key Infrastructure (PKI) 2nd
public key policies, security
public key records
public keys
public namespaces
published applications, installing
published namespaces 2nd
publishing
broadcast
DFS roots
media-integrated presentations
on-demand
publishing applications
publishing points
broadcasts, playlists
delivery methods
names 2nd
on-demand, playlists
single video broadcasts
summary
pull partners, configuring
pull record filtering
pulling media content 2nd
push partners, configuring
pushd command
pushing
client updates, Group Policies
media content
PXE (pre-boot execution) 2nd


Q

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

q command-line parameter
DCDIAG 2nd
NetDiag
Pathping command
Qchain utility
Quarantine Policy Check 2nd
CM profiles
components
downloading
installing
post-connection execution script
remote access clients
quarterly maintenance
AD database
administrator passwords, changing
storage limits
queries
DNS
forwarders
Query.exe
queues
applications
printers, redundancies
quick formatting (partitions)
quit command
quorum (cluster), backing up
quorum disks
quota templates, creating in FSRM
quotas [See also storage.]
NTFS volumes
volumes


R

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

R parameter
Pathping command
Tracert utility
r parameter
Netstat
PING command
R2 components
RAID (Redundant Arrays of Inexpensive Disks) 2nd
RAID 5 volumes 2nd
RARP (Reverse Address Resolution Protocol)
Rbfg.exe
RDP ports, configuring
Read and Apply Group Policy, security properties
real-time live broadcasts
Media Services configuration
starting
real-time storage reports, creating in FSRM
reboot mode
rebuilding server failures
recoveries [See also ASR (Automatic Server Recovery).]
recovering
AD databases
boot failures
cluster services
data
reparse points
shadow copies
disk failures
domain controllers
files/folders
IIS
Remote Storage databases
removable media databases 2nd
server failures
ASR restore
boot loader file
manual
restoring vs rebuilding
system state restore
services
systems
Recovery Console
boot failures
installing
startup, troubleshooting
recovery documents
recovery processes, single server upgrades
recovery, documenting 2nd [See also disaster recovery.]
recursive queries
Recursive Queries/Sec (DNS performance counter)
Recursive Query Failure/Sec (DNS performance counter)
recycling
redirecting
disk drives
folders
configuring
network sharing
roaming profiles
to home directories
to local user profiles
to root directories
to special paths
local resources
local time zones
My Documents folders to home directories
printers
redirections
reduced available network bandwidth
redundancy
DFS data
MOM
printer queues
Terminal Services
Redundant Arrays of Inexpensive Disks [See RAID.]
redundant domain services
redundant sites
referrals, DFS
refresh intervals, group policies 2nd
REGEDIT.EXE
REGEDT32.EXE
registerdns parameter, Ipconfig utility
RegisterInDNS test
registering components on servers
registrations, per-user class
Registry [See also Registry Editor.]
access, viewing in Security Log
architecture
auditing
backing up
cleaning
concept of
control set configurations
disk subsystem configurations
entries
event logs, analyzing
hive links
hives
HKEY_CLASSES_ROOT hive
HKEY_CURRENT_CONFIG hive
HKEY_CURRENT_USER hive
HKEY_LOCAL_MACHINE hive
HKEY_USERS hive
key permissions, setting
keys
saving
subkeys
locations
permissions, configuring
Plug and Play APIs
protecting
remote access, preventing
remote Registries, connecting to
searching
security
Security Log, analyzing
security permissions, setting
size, managing
storage
Windows .NET Server 2003, setup information
Registry Editor [See also Registry.]
Favorites menu
HKEY_USERS hive, subkeys
REGEDIT.EXE
REGEDT32.EXE
regsrv32
regular backup procedures
relative distinguished names (Active Directory)
Relative ID (RID)
relay agents, DHCP
release parameter, Ipconfig utility
reliability, applications
remote access [See also RRAS (Routing and Remote Access Server).]
authentication protocols
clients
examples
preventing
servers
remote administration
SFU
Terminal Services
Remote Assistance
applications, installing
configuring
Terminal Services
Remote Boot Floppy Generator
remote connections, Terminal Services
Remote Control Add-on 2nd 3rd
Remote Desktop 2nd 3rd
Remote Desktop Connection 2nd 3rd
Remote Desktop for Administration
installing
planning
Terminal Services
Remote Desktops MMC snap-in, Terminal Services
Remote Installation Services [See RIS (Remote Installation Services).]
Remote Installation Services for Servers
remote management, Terminal Services
remote mobile users, access
remote monitoring
remote Registries, connecting to
remote servers, viewing logs
Remote Storage 2nd 3rd
backing up
best practices
configuring
backup devices
removable media
volumes
databases, recovering
file systems
installing
media management
remote storage pools
remote users
network client Group Policy example
Terminal Services
removable media databases, recovering
removable media, Remote Storage configuration
Removable Storage Service
backing up
media pools
remote storage pools, free pools
removing [See deleting.]
Rename with Prefix option (ADMT)
Rename with Suffix option (ADMT)
renaming domains 2nd 3rd 4th
renew parameter, Ipconfig utility
repadmin utility, replication, forcing
reparse points, data recovery
replacing domain controllers
replica sets
replicas
DFS, prestaging
replication
AD (Active Directory) 2nd
collisions
connection objects
IP
latency
monitoring
multimaster replication 2nd
property version numbers
SMTP
update sequence numbers
compressing
decentralized design example
default schedule
DFS
best practices
disabling
forcing
hub-and-spoke design example
incremental universal group memberships
latency
linked-value
media-based GC/DC
schedules
selecting
site links
SMTP, selecting
testing
topology
universal group memberships
WINS
replication compression, disabling
replication connections
replication partners 2nd
replication topologies
reporting
management-level, performance documentation
MOM
routine
management-level documentation
performance documentation
security documentation
technical, performance documentation
Terminal Services
reports, storage reports (creating in FSRM)
requirements
ADMT
ADMT v2.0 domain migration
hardware
MOM
Windows Server 2003
IIS 6
Media Encoder
Media Services
Mixed-Mode Domain Redirect AD forest upgrades
networking Terminal Server
NT4 migration
RIS clients
SharePoint
software, MOM
user, Terminal Server
WSUS
resealing workstations
resolution, name
resource access, monitoring 2nd
resource distribution of networks, viewing
resource domains 2nd
resource failures, clusters
resource groups, cluster
Resource Kit tools
resource kits, MOM
Resource Leak Triage Tool
resource records [See RRs (resource records).]
resources
assigning
cluster 2nd 3rd
compatibility testing
generic cluster
local quorum
nested groups, sharing
segmenting
responses, MOM
responsibilities of team members
Responsible Person records (RP)
Restore Wizard
data recovery
system states
restores
authoritative restore
global catalog
nonauthoritative restore
partial authoritative restore
testing
restoring
boot loader files
CA certificates
CA databases
CA private keys
Certificate Services 2nd
clusters
evicting/rebuilding failed nodes
failed nodes
nodes after cluster failure
previous states
single nodes with server failure
single nodes with service failure
DHCP
DHCP data
DNS zones
Group Policies 2nd
Registry keys
server failures
system state
SYSVOL folders
WINS data
restricted groups, security
restricting
addresses
logins
physical access
restructuring NT4 domains
Resultant Set of Policies [See RSOP (Resultant Set of Policies).]
results, compatibility testing
retail media activation keys
retiring
domain controllers
existing forests
ghost domain controllers
temporary domain controllers
retrievals, user-level (archived file copies)
retrieving event logs
Return to OS Choices Menu
Reverse Address Resolution Protocol (RARP)
reverse lookup zones
reviewing documentation
RID (Relative ID) master (OM role)
RidManager test
Rights Management Services (RMS)
rights, Group Policies
assigning
management
ring topology
RIP for IP routing protocol
RIP for IPX routing protocol
RIP parameters window
RIS (Remote Installation Services) 2nd
client requirements 2nd
configuring
deployments, planning
DHCP, configuring
improvements
installing
Windows XP image customizations
RIS for Servers (Remote Installation Services for Servers)
RIS Wizard
risk and speed, comparing
RMS (Rights Management Services) 2nd
roaming profiles, redirected folders
roaming user profiles 2nd
RoboMon Web site
roles [See also server roles.]
OM (operations master)
servers, defining
of team members
user requirements in migration process
rolling upgrades, cluster nodes
root directories, redirecting to folders
root paths, creating folders
roots
DFS
creating
publishing
DNS 2nd
domain DFS
domains, cross-forest trusts
peer-root domain model
Route command
Route Table Manager, RRAS
routers, documenting configurations
routine reporting
management-level documentation
performance documentation
security documentation
Routing and Remote Access MMC Snap-in
Routing and Remote Access Server [See RRAS (Routing and Remote Access Server).]
Routing and Remote Access Server Setup Wizard
RP (Responsible Person) records
RRAS (Routing and Remote Access Server) 2nd
AAA
BITS
configuring
connection manager
Dynamic Interface Manager
installing 2nd
IP filtering driver
IP Multicast Forwarder
IP multicast routing protocols
IP Router Manager
IP Unicast Forwarder
IPX filtering driver
IPX forwarder driver
IPX Router Manager
management applications
Multicast Group Manager
NAT Traversal
PPoE Dial-On-Demand
Quarantine Policy Check
Route Table Manager
SNMP agent
TAPI
unicast routing protocols
UPnP
utilities
VPNs
RRAS Clients window
RRAS Setup Wizard
RRs (resource records) 2nd
AAAA
CNAME
host
ISDN
KEY
MB
multiple
MX
NS
PTR
RP
scavenging
SOA
SRV
WKS
RSOP (Resultant Set of Policies) 2nd 3rd
group policies 2nd
login mode
planning mode
simulation mode
RSOP MMC snap-in
Rtm.dll
Run As command 2nd
run profiles, management agents
RunMOMScript
running applications


S

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

s command-line parameter
S parameter
PING command
Tracert utility
s parameter
Arp
DCDIAG 2nd
Netstat
Safe mode
Safe Mode with Command Prompt
Safe mode with networking
SAM subkey (HKEY_LOCAL_MACHINE hive)
SamAccountName attribute
sample scripts, local group membership, checking
SANs (Storage Area Networks)
SAP for IPX routing protocol
SAP parameters window
saving
captured frames
log files
Registry keys
scalability
IIS 6
MOM
single quorum cluster
Terminal Services
scavenging RRs
schedules
replication default
replication, selecting
scheduling storage reports in FSRM
schema master (OM role)
Schema MMC Snap-in
schema objects, deleting Active Directory
schemas
AD
customizing
extending
modifying with ADSI (Active Directory Service Interfaces)
objects
upgrading
attributes, deactivating
modifications
scope of projects
scope of work, defining
scopes
AD groups
DHCP
groups in Active Directory
Multicast
standby failover approach
SuperScope (DHCP)
screen content, capturing
screen savers, password protection
screens, Performance Console startup
scripting
AD
AD searches
ADuser.vbs script
advantages
ASP
creating users from CSV files
directory administration scripts
documented instruction scripts
domain printer, example
Exchange 2000
overview
Quarantine Policy Check post-connection execution script
sample scripts
creating users from CSV files
domain printer
installed software components, searching 2nd
orphaned Group Polices, searching 2nd
volume free space
server management scripts
Subsystem for Unix-based Applications
system
user configuration scripts
user management
users
attributes, populating
creating
users from file data
Csvde.exe
flat file connections
flat file data source connections
Ldifde.exe
VBScript
volume free space
WMI
workstation management scripts
WSH
scripts
assigning
computer startup, assigning
Group Policy
Logarchive.vbs
startup, logon.bat files, adding as
unattended installations
example
launching
Scripts (Logon/Logoff) extension
Scripts (Startup/Shutdown) extension
SCW (Security Configuration Wizard)
searching
AD
Group Policies
installed software script
orphaned Group Policies, sample script
Registry
WINS
secondary subsystems
secondary zones 2nd
secure channels, .NET Passport
Secure Socket Layer [See SSL (Secure Sockets Layer).]
secure templates
Secure Update Received/Sec (DNS performance counter)
Secure Update Received/Sec/Sec (DNS performance counter)
secure updates, DNS
securing FTP
security
.NET Passport
access, restricting
account policies
Active Directory 2nd
administrative access
anonymous authentication
antivirus programs
authentication
authorization
backup
basic authentication
Certificate Services 2nd
certificates
Client Authentication certificate purpose
CLR
DHCP
digest authentication
Directory Services Restore Mode
EFS
encryption
event logs
file systems
file-level
firewalls 2nd
fix consistency
FTP
GPOs (Group Policy Objects) namespaces
Group Policies
IDS (intrusion detection system)
IETF (Internet Engineering Task Force) standards
IIS 6 2nd
auditing
authentication
FTP authentication, securing
FTP security
FTP security options, configuring
FTP transfers, securing
SSL certificates
Web service extensions, locking down
Windows .NET Server 2003
improvements
integrated Windows authentication
internal audits 2nd
Internet Explorer, Enhanced Security Configuration 2nd
IPSec 2nd 3rd 4th
layers
local policies
logins, restricting
logs
migration
MOM
.NET Passport
network access
network clients
non-Microsoft Kerberos realms
Passport improvements
physical
PKI
policies
administrative controls
application-level
desktop
education
enforcing
enterprise 2nd
issue-specific
network infrastructure 2nd
organizing
procedures and checklists
system-level
technical controls
policies toolbox
CAs
MBSA
monitoring tools
RMS
SCW
Security Configuration and Analysis tools
stress-testing tools
private keys
public keys 2nd
Read and Apply Group Policy properties
Registry
restricted groups
risks
Server Authentication certificate purpose
servers
services, turning off
share-level, NTFS, compared
smartcards 2nd
software restriction policies
SUS
system services
templates
Terminal Services
transport-level
Trustworthy Computing initiative
updating
VPNs
administration
L2TP/IPSec
RRAS
Tunneling protocol
tunnels
Windows .NET Server
wire
wireless improvements
wireless network policies
WSUS
Automatic Updates client configuration
customizing
history
installing
requirements
synchronizing
updates, approving
updates, deploying
Security Accounts tab (FTP Sites folder properties page)
Security Configuration and Analysis tool
Security Configuration Wizard (SCW)
security documentation
security framework
security groups 2nd
permission sharing
SID (Security ID)
universal
Security ID (SID)
Security Log 2nd
Security Monitor (IPSec)
security permissions, setting
Security Settings (Computer Configuration and User Configuration)
SECURITY subkey (HKEY_LOCAL_MACHINE hive)
security templates, Group Policies
security-based configuration groups (MOM)
segmenting resources
selecting
authentication protocols
Cluster Service applications
clustering technologies
DFS types
licensing modes
migration paths
unattended installations
VPN protocols
Server Authentication certificate purpose
server failures
hard drive failures
recovering from
ASR restore
boot loader file
manual
restoring vs rebuilding
system state restore
software corruption
server farms
server management
domain controllers
file servers
print servers
server roles
terminal servers
Web servers
server management scripts
Server parameter, Nslookup
Server Performance Analyzer (SPA 2.0)
server roles
for performance optimization
server management
server settings, Terminal Services Configuration MMC snap-in
Server Status Monitor (SSM)
servers [See also Windows Server 2003; Windows .NET Server.]
application
ASR (Automatic Server Recovery)
build documents
caching-only
cluster
components, registering
configuration documentation
CYS (Configure Your Server) Wizard
D-DCAM, MOM
DAS
databases
MOM
monitoring
DC (domain controller)
DCAM, MOM
DFS (Distributed File Systems)
DHCP (Dynamic Host Configuration Protocol) 2nd 3rd
DNS (domain name service)
domain member, migrating
domains, volume free space script
file 2nd 3rd
forwarders
functionality, testing
global catalogs 2nd 3rd
IIS 6 requirements, determining
Internet Information Server and Site Server
IP addresses
IPSec policies
licensing
maintenance 2nd
management scripts
managing
media
messaging, monitoring
migration documentation
NT4 migration requirements
pilot phase, Windows Server 2003 migration
print 2nd 3rd
remote access
remote management
RIS for Servers
RRAS
security
Session Directory 2nd
SharePoint Portal
single server upgrade
standalone server upgrade
storage
Telnet, SFU remote administration
temporary, promoting
terminal 2nd
application installations
fault tolerance
hosted applications
networking requirements
placement
upgrades
TS License
types, Windows Server 2003
virtual, clustering
VPN
Web 2nd 3rd
Web application server settings
Windows Software Update Server
WSS, updates/patches
service accounts
migrating into AD
MOM 2nd
service agreements, .NET Passport
service packs (SPs)
command-line parameters
consistency
deploying
SUS
Terminal Services
Windows Server 2003 updates
Windows Update
service providers, application (Terminal Services)
Service records (SRV)
Service tab (Default Web Site Properties page)
service updates/patches, compatibility
Service-Level Agreements (SLAs) 2nd
Services 2nd [See also Web Services.]
Active Directory
applications, compared
backing up 2nd
Certificate Services
DFS
DHCP databases
disk configuration
DNS
IIS metabase
Remote Storage Service
Removable Storage Service
WINS
dependencies
DHCP client
DHCP server
FTP, installing and configuring
IIS 6 Admin
Indexing Service, IIS 6
Media
configuring
installing
load testing
performance
playlist broadcasting, configuring
playlists, starting
real-time live broadcasts
single video broadcasts
system requirements
video directories
network, new features
NLB clusters
NNTP Service, IIS 6
recovering
Certificate Services
DHCP data
DNS zones
WINS data
redundant domain
SharePoint
access
alerts
customizations
discussions
document libraries
document management 2nd
file uploads
FrontPage 2003 integration
full SQL Server 2000 instances
installing
interface
lists 2nd
meeting workspaces
Office 2003 integration
personal sites
personalizing
picture libraries
Portal Server
presence menus
requirements
site customizations
Site Directory
site templates
surveys 2nd
team collaboration
Team Services
technologies
templates
Word Shared Workspaces
workspace
WSS server updates/patches
SMTP Service
systems, security
Terminal [See Terminal Services.]
turning off
users
Web, configuring
X.500 directory
Services agreement (.NET Passport)
Services for NetWare [See SFNW (Services for NetWare).]
Services for UNIX [See SFU (Services for UNIX).]
Services test
Session Directory 2nd
Session Directory server 2nd
Session pane, Netmon
sessions, capturing media
set audit-logging command
set loglevel command
set machine command
set mode command
setclassid parameter, Ipconfig utility
Setup Manager
unattended installations
Windows XP deployment
setup wizards
SETX.exe utility
Sfc.exe (System File Checker)
SFNW (Services for NetWare) 2nd
FMU
FPNW
installing
MSDSS
SFU (Services for UNIX)
administration
components
development
installing
NFS
prerequisites
Subsystem for Unix-based Applications
user synchronization
shadow copies
best practices
configuring 2nd
data recovery
deleting 2nd
managing
Shadow.exe
share-level security, NTFS, compared
shared disks, backing up clusters
Shared Document page, actions
shared nothing architecture
shared printers, adding
shared storage devices, Cluster Services
Shared Workspaces, Word
SharePoint 2nd
access
alerts
customizations
discussions
document libraries
document management 2nd
file uploads
full SQL Server 2000 instances
installing
interface
lists
advantages
editing
listing of
viewing
meeting workspaces
Office 2003 integration
personal sites
personalizing
picture libraries
Portal server
pre-installation steps
presence menus
requirements
servers, updates/patches
Site Directory
sites
customizing
FrontPage 2003 integration
templates
surveys 2nd
team collaboration
Team Services
technologies
templates
Word Shared Workspaces
workspace
WSS server updates/patches
SharePoint Portal Server [See SPs.]
shares (files)
client-side caching
data recovery
DFS root
managing
permissions
sharing security group permissions
shortcut trusts 2nd
show alias command
show audit-logging command
show helper command
show loglevel command
show machine command
show mode command
show netdlls command
show version command
showclassid parameter, Ipconfig utility
shuffling videos
SID (Security ID) 2nd
signature-based detection
signing
drivers
File Signature Verification
Sigverif.exe (File Signature Verification)
Simple Mail Transport Protocol (SMTP)
Simple Network Management Protocol (SNMP)
simple volumes
single domain model
single forest model
single host mode (port filtering)
single node cluster, Cluster Service configuration
single nodes, restoring
server failure
service failure
single quorum cluster, scalability
single quorum device cluster, Cluster Service configuration
single server MOM configuration
single server upgrade, Windows 2000 to Windows Server 2003 migration
single sign-in [See SSI (single sign-in).]
single sign-on
single video broadcasts
single-site designs
Site Directory, SharePoint
site failures
client connectivity
creating
failing back
failing over between sites
failover sites
planning
redundant sites
Site Group Policies, AD sites
site link bridgeheads, Active Directory replication
site links, Active Directory replication
site-to-site connections
sites [See also AD (Active Directory), sites, structure; FTP (File Transfer Protocol), sites, creating.]
Active Directory replication
SharePoint
customizing
FrontPage 2003 integration
structure
six states (compatibility)
size
MOM databases
Registry, managing
skip parameter
DCDIAG 2nd
NetDiag
SLAs (service-level agreements) 2nd
slipstreaming Service Packs
slow links, group policies
smartcards 2nd
SMS (Systems Management Server) 2nd
SMTP (Simple Mail Transport Protocol)
encrypting
replication
SMTP replication, selecting
SMTP Service
snap-in namespaces (Group Policy)
Computer Configuration
Computer Configuration/Administrative Templates
Computer Configuration/Security Settings
Computer Configuration/Software Settings
Computer Configuration/Windows Settings
Scripts
Software Installation Service
User Configuration
User Configuration/Administrative Templates
User Configuration/Security Settings
User Configuration/Software Settings
User Configuration/Windows Settings
snap-ins, Group Policy
configuring
IIS, configuring IIS 6
opening
SNMP (Simple Network Management Protocol)
SNMP agent, RRAS
SOA (Start of Authority) records
soft faults (memory)
software
clients, installations
compatibility list Web site
corruption
desktop, installing
error reporting
installed components, searching for script
installing group policies
MOM requirements
multicast imaging
NT4 migration compatibility
Sharepoint requirements
third-party application packaging
third-party imaging
Windows Software Update Server
Software Installation Service (Group Policy)
software restriction policies, security
Software Settings (Computer Configuration and User Configuration)
SOFTWARE subkey (HKEY_LOCAL_MACHINE hive)
Software Update Services [See SUS (Software Update Services).]
solutions to problems, implementation approach (design documents)
SONAR, FRS, monitoring
Sonar.exe
source property, logs
SPA 2.0 (Server Performance Analyzer)
spaghetti domain structure (Windows NT4)
spanned volumes
special paths, redirecting folders
special-purpose domains
speed and risk, comparing
speed, slow links
spreadsheet data, SharePoint list of
SPs [See Terminal Services, service packs.]
SPS (SharePoint Portal Server)
SQL Server 2000 instances, SharePoint
SQL Server databases, MIIS
SRV (Service) records 2nd
SSI (single sign-in)
SSL (Secure Sockets Layer) 2nd
.NET Passport
certificates
applying
CAs, requesting
IIS 6 security
requesting for Web sites
SSM (Server Status Monitor)
staging folder
standalone root CA 2nd
standalone server upgrade, Windows 2000 to Windows Server 2003 migration
standalone subordinate CA 2nd
standard and AD-integrated DNS zones, comparing
Standard edition of Windows Server 2003
standards
group naming
Internet, Microsoft adoption
Windows Server 2003
standby scopes failover approach
Start Menu, limiting
Start of Authority records (SOA)
Start Windows Normally
starting
playlists
real-time live broadcasts
startup
troubleshooting
startup screens, Performance Console
startup scripts, logon.bat files
state, backing up systems
Statement of Policy (Microsoft)
static IP addresses
Station Statistics pane, Netmon
status, monitoring DFS
steps of migration projects, defining
storage
data, MOM
DNS zones
file systems
Registry
Remote Storage
backing up
best practices
configuring
installing
Removable Storage Service, backing up
servers
shared storage devices, Cluster Services
Storage Area Networks (SANs)
storage limits, checking
storage management, FSRM
configuring user storage limits
creating
file screen templates
file screens
quota templates
storage reports
installing
storage reports, creating in FSRM
stress-testing tools
string values
striped sets with parity, NT4 migration
striped sets, NT4 migration
striped volumes
structured design documents
structures
Active Directory 2nd
authentication modes
domain trees
domain trees and subdomains
domains
forests
functional levels
Kerberos
mixed domain functional level
NTLM (NT LAN Manager)
placeholder domains
sites
Windows .NET Interim mode (interim domain functional level)
Windows 2000 Native mode (native domain functional level)
Windows Server 2003 domain functional level
domains, choosing
groups, designs
OUs (organizational units)
designs
nesting
text hierarchy
spaghetti domains (Windows NT4)
Windows NT4 domains
stub zones
SubCommand parameter, Nslookup
subdomains
in Active Directory
DNS
msdcs, DNS
multiple domain model
shortcut trust
subkeys
HARDWARE/ACPI subkey (HARDWARE subkey)
HARDWARE/DESCRIPTION subkey (HARDWARE subkey)
HARDWARE/DEVICEMAP subkey (HARDWARE subkey)
HARDWARE/RESOURCEMAP subkey (HARDWARE subkey)
HKEY_CURRENT_USER hive
HKEY_LOCAL_MACHINE hive
HKEY_USERS hive
Registry
subnets
AD sites
AD sites association
creating
site associations
Subsystem for Unix-based Applications
subsystems
disk, evaluating
network, monitoring
secondary
Superscope (DHCP)
support
Terminal Services
command-line tools
disabling
disaster recovery
remote management
service packs
Terminal Server Manager
updating
users
WMI
Unicode characters, DNS
Surveys, SharePoint 2nd
SUS (Software Update Services) 2nd 3rd [See also history, WSUS.]
Automatic Updates Client
download
hotfixes
SPs
Windows Update
switch flooding, NLB clusters
switches, documenting configurations
Synchronization dialog box
synchronization interface, Producer
synchronizing
global catalog
passwords, SFU
WSUS
syntax, DCDIAG
sysprep
system compatibility, server upgrades
system events
auditing
monitoring
System File Checker
system files, File Protection
system logs
system memory, monitoring
System Monitor
counters
displays
FRS, monitoring
multiple configurations
performance
remote monitoring
system performance
disk subsystems, evaluating
monitoring
NBT Connection: Bytes Total/sec (network traffic counter)
NBT Redirector: Bytes Total/sec (network traffic counter)
NBT Server: Bytes Total/sec (network traffic counter)
network subsystems, monitoring
processor usage, analyzing
system memory, monitoring
thrashing
System Preparation Tool, Windows XP deployment
system root security templates
system services, security
System Startup and Recovery utility
system state, restoring
SYSTEM subkey (HKEY_LOCAL_MACHINE hive)
system usage policies
system volumes
backing up
disk failures
system, scripting
system-level security policies
systemlog test
systems
disk subsystems, evaluating
fault-tolerant
application reliability
creating
network hardware
server storage
UPSs
file
DFS [See file systems, DFS.]
FRS
remote storage
security
VSS
managing MOM
monitoring
CLFS
Performance Logs and Alerts utility
performance monitoring tools
System Monitor utility
tools
trace logs
network subsystems, monitoring
networks, inventory
processes running
recovering
state, backing up
Systems Management Server (SMS) 2nd
SYSVOL folders, restoring


T

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

T parameter, Pathping command
t parameter, PING command
table of contents (sample)
design documents
migration documents
tables, migrating (Group Policies)
TAKEOWN.exe utility
TAPI (Telephony Application Programming Interface)
TargetName parameter, PING command
targets
adding DFS
offline
Task Manager 2nd
applications
capacity analysis
launching
networks
performance
processes
user activity
window
window tabs
Taskbar, limiting
tasks
assigning
automating [See scripting.]
delegating
delegation control
maintenance
SharePoint list of
simplifying
of Windows Server 2003, simplifying
TCP Query Received/Sec (DNS performance counter)
TCP Response Sent/Sec (DNS performance counter)
TCP/IP (Transmission Control Protocol/Internet Protocol) 2nd
information window
tools
Arp
DCDiag
Ipconfig
NetDiag
Netstat
Nslookup
Pathping
PING
Route command
Tracert
team members, roles and responsibilities
Team Services (SharePoint)
teams
technical controls, security policies
technical goals and objectives, identifying
deployment team participants, defining
design team participants, defining
scope of work, defining
timeframes (implementation or migration), determining
technical reporting, performance documentation
technical training
technologies
clustering
SharePoint
Telephones, system activation
Telephony Application Programming Interface (TAPI)
Telnet
remote access management
SFU remote administration
template user profiles
templates
administrative
add-on
baseline Outlook preferences
customizing 2nd
delegates
managing
Outlook 2nd
Policies vs preferences
rights, assigning
Administrative Templates (Computer Configuration and User Configuration)
security 2nd 3rd
SharePoint
Software Installation Service (Group Policy)
temporary domain controllers
Mixed-Mode Domain Redirect AD forest upgrades
retiring
temporary NT domain controllers, Mixed-Mode Domain Redirect AD forest upgrades
temporary servers, promoting
temporary user profiles
Terminal Server
application installations
fault tolerance
hosted applications
networking requirements
Terminal Server Manager
Terminal Server mode
installing
planning
terminal servers 2nd
Terminal Services
access
AD Users and Computers MMC snap-in
application service providers
client-side
command-line tools
Computer Management tool
Configuration MMC snap-in
configuring
console access
deploying
disabling
disaster recovery
fault tolerance
network load balancing
session directory server
granular session control
Group Policy
LAN users
License server
licensing
Licensing Reporter
local resource redirections
Local Security Policy snap-in
modes of operation
overview
performance 2nd
planning
remote administration
Remote Desktop for Administration
installing
planning
remote management
remote users
reporting
scaling
security
server placement
server upgrades
service packs
Session Directory server
supporting
Terminal Server Manager
Terminal Server mode
installing
planning
thin client
updating
users support
WMI
Terminal Services Configuration (TSCC) snap-in
Terminal Services Configuration MMC snap-in
connections
server settings
test parameter
DCDIAG 2nd
NetDiag
test plans, migration documentation
test user accounts
test workstations
testing
advertising
CheckSDRefDom
clusters
compatibility
ACT
application inventory
application priority
applications vs services
applications, installing
basic
budget
checklist
complete
documentation
extent
goals
hardware allocation/configuration
inventory application sheets
mid-level
network systems inventory
plan, documenting
preparations
prototype phase
resources
results, documenting
scope
testing lab
timeframe
training
upgrades
user involvement
vendors [See vendors, compatibility information.]
Windows Server 2003 allocation/configuration
connectivity
CutoffServers
DCPromo
frssysvol
FsmoCheck
Intersite
IPSec 2nd
kccevent
KnowsOfRoleHolders
load, Media Services
MachineAccount
NCSecDesc
NetLogons
ObjectsReplicated
OutboundSecureChannels
RegisterInDNS
replications
restores
RidManager
server functionality
Services
systemlog
topology
updates
UPS
WSUS updates
testing labs, compatibility testing
testing process of labs, results
tests, DCDIAG
text format (txt)
text, hierarchies (OU structures)
thin client Terminal Services
third-party application packaging software
third-party imaging software
third-party toolsets for capacity analysis
thrashing system performance
ticket cookies
tier environments, fault tolerances
time and date, configuring
time property, logs
Time to Live (TTL) 2nd
time zones (local), supporting
timeframes 2nd
TIMEOUT.exe utility
tolerance [See fault tolerance.]
toolboxes, security policies
CAs
MBSA
monitoring tools
RMS
SCW
Security Configuration and Analysis tools
stress-testing tools
toolsets
built-in for capacity analysis
Network Monitor
Performance Console
Task Manager
third-party for capacity analysis
topologies
replication
compression
domain controllers, promoting
encrypted SMTP
ISTG
lingering objects
linked-value replication
multiple-site designs
replication schedules
schema changes
single-site designs
site costs
site design
site links
sites, establishing
SMTP
subnet associations
universal group caching
WAN design
Windows Server 2003 improvements
testing
Total Query Received/Sec (DNS performance counter)
Total Response Sent/Sec (DNS performance counter)
trace logs
Tracert 2nd
tracing files
tracking sheets, vendor compatibility
traffic of networks, monitoring
training
documentation
end-user
projects
technical
Transaction Processing Performance Council Web site
transfers, securing FTP
transitive trusts 2nd
Translate Roaming Profiles option (ADMT)
translations, NAT
Transmission Control Protocol/Internet Protocol [See TCP/IP (Transmission Control Protocol/Internet Protocol).]
transport-level security
Certificate Services
certificates
EFS
encryption
IPSec
multiple levels
non-Microsoft Kerberos realms
PKI
private keys
public keys
smartcards
VPNs
trees
Active Directory domains
Active Directory forests
cross-forest transitive trusts
cross-forest trusts
DFS
federated forests design model
real-world design example
single forest model
triangle diagrams (domains)
triggers, configuring captures
troubleshooting
DNS
DNS island problem
documentation
Group Policies
pilot phase (migration)
startup
tools
Dr. Watson for Windows
memory
software error reporting
System Startup and Recovery
TCP/IP [See TCP/IP (Transmission Control Protocol/Internet Protocol).]
Windows XP image errors
trust design sample
domains 2nd
explicit 2nd
external
passwords
shortcut
shortcut between subdomains
transitive 2nd
trusts
cross-forest 2nd
cross-forest transitive 2nd
domain (Active Directory) 2nd
Trustworthy Computing initiative
TSCC (Terminal Services Configuration) snap-in
tskill.exe
TSShutdn.exe
TTL (Time to Live) 2nd
Tunneling protocol, VPNs
tunneling VPNs 2nd
turning off services
two-way trusts, creating
txt (text format)
type property, logs


U

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

u parameter 2nd 3rd
UDP listener ports window
UDP Query Received/Sec (DNS performance counter)
UDP Response Sent/Sec (DNS performance counter)
unattend.bat file example
unattended installations
preparations
script
selecting
Setup Manager
unicast delivery, multicast delivery (compared)
Unicast mode (clusters)
unicast routing protocols
Unicenter TNG Web site
Unicode characters, DNS support
Uninterruptible Power Supplies (UPSs) 2nd
universal distribution
universal group caching 2nd 3rd
universal group memberships, replicating
universal groups 2nd 3rd 4th
Universal Plug and Play (UPnP)
universal security
UNIX, SFU
ActivePerl 5.6
components
development
installing
NFS
NIS users, adding to Active Directory
password synchronization
prerequisites
remote administration
Subsystem for Unix-based Applications
User Name Mapping
user synchronization
unlinking GPOs
unpopulated placeholder domains
Update Previously Migrated Objects option (ADMT)
update sequence numbers (USNs)
updates
Automatic Updates Client
client
desktop images
DNS
documentation 2nd
dynamic DNS
Feature Packs
printer drivers
security
services, compatibility
SUS
Terminal Services
testing
Windows Automatic Update, patch management
Windows Server 2003
Windows Software Update Server
Windows Update 2nd
Windows XP/2000 workstations
WSS servers
WSUS 2nd
upgrade decision matrix
upgrades
AD
AD schema
BDC
cluster nodes
domain controllers 2nd
functional levels
IIS 6
last node rolling
logs, reviewing
NT4 domains
rolling cluster nodes
single server
standalone server
Terminal Servers
testing
versions, compatibility
Windows 2000 AD forest
AD-Integrated DNS zones, moving
domain controller migration
domain controller upgrade
functional levels, upgrading
ghost domain controllers
OM roles
replacing domain controllers
retiring domain controllers
schema upgrade
Windows 2000 AD forest Mixed-Mode Domain Redirect
existing forest, retiring
NT PDC promotion
OM roles
production domain controllers
re-establishing domain controllers
requirements
secondary temporary server
temporary domain controllers
Windows Server 2003 2nd
WINS environment
uploading files, SharePoint
UPN (user principal name)
UPnP (Universal Plug and Play)
UPS (Uninterruptible Power Supply) 2nd
User Account Migration Wizard, user accounts
user accounts, migrating (ADMT v2.0 domain migration)
user activity, monitoring Task Manager
user administration
forest
single domains
user configuration scripts
User Configuration, Group Policy snap-in namespaces
Administrative Templates
Security Settings
Software Settings
Windows Settings
user isolation
FTP
settings
user management scripts
User Name Mapping, SFU
user principal name (UPN)
user property, logs
user services
user storage limits, configuring in FSRM
user synchronization (SFU)
user-level retrieval, archived file copies
users
attributes 2nd
compatibility testing involvement
creating
from CSV files script
from file data scripts
end-user satisfaction, verifying
folders
FTP, isolating
Group policies
home, access
LAN, Terminal Services
management scripts 2nd
migration documentation
mobile, network client Group Policy example
pilot phase of migration testing
policies 2nd
power users, supporting
profiles 2nd
remote
network client Group Policy example
Terminal Services
remote mobile, access
roaming profile, creating
Terminal Server requirements
Terminal Server support
Users folders, objects
Users tab (Task Manager window)
USNs (update sequence numbers)


V

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

v parameter
DCDIAG 2nd
NetDiag
PING command
validating
backups
failures, application dependencies
values
variables, CurrentTime
VBScript
VDS (Virtual Disk Service)
vendors, compatibility information
incompatible applications
service updates/patches
six states
testing plan, assessing
tracking sheets
upgrade decision matrix
version upgrades
Windows Server 2003-compatible applications
verification
backups
end-user satisfaction
hardware
VeriTest Web site
versions
upgrading for compatibility
Windows Server 2003
video
screen content, capturing
single video broadcasts [See single video broadcasts.]
video directories
configuring
files, viewing
video files
converting
extensions
video-editing tools
viewing
applied policies
event properties
files, video directories
group policies
IPSec Security Monitor
logs, remote servers
network resource distribution
policies
Registry access in Security Log
SharePoint lists
virtual directories
Virtual Disk Service (VDS)
virtual interfaces window
Virtual Private Networks [See VPNs (Virtual Private Networks).]
virtual servers, clustering
visual changes (Windows Server 2003)
volume free space script
volume media activation keys
volume sets, NT4 migration
Volume Shadow Copy Service [See volumes, VSS.]
volumes
basic
boot
backing up
disk failures
data
backing up
disk failures
dynamic
fault-tolerant, creating
mirrored
monitoring
NTFS, quotas
RAID 5 2nd
Remote Storage configuration
simple
spanned
striped
system
backing up
disk failures
VSS
Backup utility
data recovery
shadow copies, configuring
shadow copies, deleting
shared storage
VPNs (Virtual Private Networks) 2nd
administration
client configuration
connections
L2TP/IPSec
protocols
RRAS
Tunneling protocol
tunnels
VSC, data recovery
VSS (Volume Shadow Copy Service) 2nd 3rd 4th 5th
Backup utility
data recovery
limitations
shadow copies
best practices
configuring 2nd
deleting
managing
shared storage
vssadmin.exe


W

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

w parameter, PING command
WAN
connections, documenting
links, configuration groups
network configuration documentation
WAS (Web Administration Services)
Web Application Server dialog box
Web applications, server settings
Web clients, Terminal Services access
Web console, MOM
Web content
Web edition of Windows Server 2003
Web Gardens, applications
Web Server (ADFS)
Web Server Certificate Wizard
Web servers 2nd 3rd
Web Service Extensions
Web Services
configuring
extensions, locking down
XML, supporting
Web Site tab (Default Web Site Properties page)
Web-based applications, .NET Passport integration
weekly maintenance
archive event logs, checking
DCDIAG
Disk Defragmenter, running
disk space, checking
hardware verification
Well Known Service records (WKS)
WHERE.exe utility
WHOAMI.exe utility
WHQL (Windows Hardware Quality Lab)
Windows .NET Application Host
Windows .NET Framework
Windows .NET Interim mode (interim domain functional level)
Windows .NET Server
Interim domain level
maintenance
daily
monthly
quarterly
weekly
Native domain level
security
single domain with OUs
Windows 2000
installing
migrating to Windows Server 2003 2nd
workstations, updating
Windows 2000 AD forest
Mixed-Mode Domain Redirect upgrade
existing forest, retiring
NT PDC promotion
OM roles
production domain controllers
re-establishing domain controllers
requirements
secondary temporary server
temporary domain controllers
temporary domain controllers, retiring
temporary NT domain controllers
upgrading
AD-Integrated DNS zones, moving
domain controller migration
domain controller upgrades
functional levels, upgrading
ghost domain controllers
OM roles
replacing domain controllers
retiring domain controllers
schema upgrade
Windows 2000 Mixed mode 2nd 3rd
Windows 2000 Native mode 2nd 3rd
Windows 2003 R2 components
configuring
installing
preparing installation
Windows Add Printer option
Windows Application Compatibility Toolkit 2nd
Windows Application Verifier
Windows Automatic Update, patch management
Windows Backup utility [See Backup utility.]
Windows Hardware Quality Lab (WHQL)
Windows Installer Cleanup Utility (MSICUU)
Windows Installer Zapper (MSIZAP)
Windows Internet Naming Service [See WINS (Windows Internet Naming Service).]
Windows Management Instrumentation [See WMI (Windows Management Instrumentation).]
Windows Media Encoder [See Media Encoder.]
Windows Media Load Simulator
Windows NT 4
domain structure 2nd
resource domains
Windows Server 2003, migrating to
Windows NT 4 domains
Windows NT 4 groups, migrating into AD
Windows NT 4 SAM database
Windows NT 4 to Windows Server 2003 migration
compatibility services
existing domains to Windows Server 2003 forest
account/resource domains
domain installation
domain trusts
security
hardware/software compatibility
hardware/software requirements
inplace upgrade
AD upgrade
backup domain controllers
BDC upgrade
Directory Services Restore Mode security
domain controller upgrades
domain member servers
forest functionality levels
starting
migration paths
domains, consolidating
inplace upgrades
selecting
mirrored volumes
NT4 SAM database
operating system requirements
preparations
server requirements
striped sets
striped sets with parity
volume sets
Windows NT 4 to Windows Server 2003 migration paths, Windows Server 2003 forest
Windows NT resource domain layouts, mapping OU designs
Windows Rights Management [See RMS (Rights Management Services).]
Windows Script Development Center
Windows Scripting Host (WSH) 2nd 3rd
Windows Server 2003
activating
Active Directory
add-in applications
administration benefits
allocating compatibility testing
application server functions
cluster servers
collaborative design decisions
configuring compatibility testing
DataCenter edition
design agreements
design decisions
design phase
DFS server
DHCP server
directory services
discovery phase
DNS (domain name service) server
domain controller
domains, renaming
end state (technology configurations)
end-user satisfaction, verifying
Enterprise edition
environment, supporting
executive summaries 2nd
File Server Resource Manager (FSRM)
GANTT charts
geographical depth and breadth
global catalog servers
global catalog servers, building
Group Policies installations
image installations
implementing
information overload management
installing
administrator passwords
alternative methods
computer names 2nd
date and time
domain names
existing domains, joining
file backups
hardware requirements
information, gathering
IP addresses
languages
licensing modes
network settings
new installation
operating system
partitions, formatting
personalizing
product keys
server types
upgrade
workgroup names
IPSec NAT Transversal
lab testing process results
labs, building
logging in
maintenance
daily 2nd
MMC 3.0
monthly
quarterly
weekly
management improvements
ASR
Out-of-Band Management
RIS for Servers
media servers
migration documents, creating
migration planning phase
migration process goals and objectives
migration/implementation phase
migrations 2nd
ADMT (Active Directory Migration Tool)
approach to defining steps and milestones
budget estimates 2nd
business goals and objectives, identifying
network background information
new features
Active Directory schema objects, deleting
configuration wizards
dragging and dropping
functionality improvements
global catalog information, caching
global catalog synchronization
high-speed links, disabling compression
IETF security standards, supporting
interface, customizing and programming
IPSec security improvements
IPv6 standard, supporting
management wizards
Passport security improvements
performance improvements
security improvements
setup wizards
standards, supporting
tasks, simplifying
visual changes
wireless security improvements
XML Web Services, supporting
pilot phase
pilot results, documenting
pilot users, application usage requirements
pilot users, geographical diversity
pilot users, quantity of
pilot users, role requirements
Print Management Console (PMC)
problem solving
project goals and objectives
project plans
project scope
prototype phase
prototype testing phase project plan
remote access servers
Service Pack updates
setup information
SMS installations
solutions, implementation approach
speed and risk, comparing
Standard edition
structured design documents, organizing information
table of contents (sample) 2nd
team members' roles and responsibilities
technical goals and objectives, identifying
terminal servers
thin client Terminal Services
unattended installations
preparations
script
script example
script launching
selecting
Setup Manager
upgrading
user services
versions
Volume Shadow Copy
Web edition
Web servers
to Windows NT4
to Windows 2000
Windows .NET Framework, comparing
Windows 2000, migrating to
Windows NT4, migrating to
x64-bit edition
Windows Server 2003 domain functional level 2nd
Windows Server 2003 forest, NT4 migration
account/resource domains
domain installation
domain trusts
security
Windows Server Update Services [See WSUS (Windows Server Update Services).]
Windows Settings (Computer Configuration and User Configuration)
Windows SharePoint Services (WSS) [See SharePoint.]
Windows Software Update Server
Windows System Resource Manager [See WSRM (Windows System Resource Manager).]
Windows Terminal Services [See WTS (Windows Terminal Services).]
Windows Update
hotfixes
SPs
Web site 2nd 3rd
Windows XP
desktop management
image deployment
deployment tools
desktop customization
desktop software, installing
errors
RIS customizations
tools
unattended installation
installing 2nd
remote desktop management
unattended installation
workstations, updating
WinRM, remote access management
WINS (Windows Internet Naming Service) 2nd
backing up 2nd
compacting
database maintenance
DNS integration
DNS lookups
environment
installing
LMHOSTS file
maintenance
NetBIOS resolution
new features
pull record filtering
push/pull partners
replication
replication partner acceptance
restoring
searches
wire security
wireless networks, security 2nd 3rd
WKS (Well Known Service) records
WMI (Windows Management Instrumentation) 2nd
Filters
scripting
system scripting
Terminal Services
Word, creating Shared Workspaces
work, scope of
worker process isolation mode (IIS 6)
workers, handlers/worker processes (applications)
workgroups, names
working sets
workload characterizations (capacity analysis)
workspaces
SharePoint 2nd
Word Shared Workspaces
workstation management scripts
workstations
administrator
locking down
management scripts
resealing
test
Windows XP/2000, updating
wrapper playlists, creating
WSH (Windows Scripting Host) 2nd
WSRM (Windows System Resource Manager) 2nd 3rd
performance optimization
Terminal Services performance
WSS (Windows SharePoint Services) [See SharePoint.]
WSUS (Windows Server Update Services) [See also SUS (Software Update Services).]
Automatic Updates client configuration
customizing
history
installing
requirements
synchronizing
updates
approving
deploying
testing
WTS (Windows Terminal Services)


X

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

X.500 directory services
x64-bit edition of Windows Server 2003
XML
documents, forest descriptions
Web Services, supporting
XMPs (Extended Management Packs)
XrML (Extensible Rights Markup Language)


Y

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

y command-line parameter


Z

Previous Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

z command-line parameter
zombies, detecting
zone transfer counters of DC (domain controller)
zone transfers
zones
AD-Integrated DNS, moving
AXFR (full zone transfers)
DNS 2nd
AD-integrated
automatic creation
forward lookup
integrated
primary
restoring
reverse lookup
secondary
standard and AD-integrated, comparing
storing
stub
zone transfers
IXFR (incremental zone transfers)
time (local), supporting